ANN: Python Meeting Düsseldorf - 16.07.2013
[This announcement is in German since it targets a local user group meeting in Düsseldorf, Germany] ANKÜNDIGUNG Python Meeting Düsseldorf http://pyddf.de/ Ein Treffen von Python Enthusiasten und Interessierten in ungezwungener Atmosphäre. Dienstag, 16.07.2013, 18:00 Uhr Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf Diese Nachricht ist auch online verfügbar: http://www.egenix.com/company/news/Python-Meeting-Duesseldorf-2013-07-16 NEUIGKEITEN * Sprint-Planung: Wir möchten im Sommer/Herbst gerne einen Sprint organisieren und suchen dafür Themen. Falls Ihr Themenvorschläge habt, wäre es schön, wenn Ihr diese auf dem nächsten Treffen kurz vorstellen könntet. Beispiele: - Progammieren eines Add-ons für XBMC - Progammieren eines Add-ons für Blender - Patch für einen oder mehrere Python Bugs schreiben * Neuer Veranstaltungsraum: Wir treffen uns im Bürgerhaus in den Düsseldorfer Arcaden. Da beim letzten Mal einige Teilnehmer Schwierigkeiten hatten, den Raum zu finden, hier eine kurze Beschreibung: Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer Arcaden. Über dem Eingang steht ein großes “Schwimm’in Bilk” Logo. Hinter der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus dem Aufzug kommt. Google Street View: http://bit.ly/11sCfiw EINLEITUNG Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python Begeisterte aus der Region wendet: * http://pyddf.de/ Einen guten Überblick über die Vorträge bietet unser YouTube-Kanal, auf dem wir die Vorträge nach den Meetings veröffentlichen: * http://www.youtube.com/pyddf/ Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting Research, Düsseldorf: * http://www.egenix.com/ * http://www.clark-consulting.eu/ PROGRAMM Das Python Meeting Düsseldorf nutzt eine Mischung aus Open Space und Lightning Talks. Lightning Talks können vorher angemeldet werden, oder auch spontan während des Treffens eingebracht werden. Ein Beamer mit XGA Auflösung steht zur Verfügung. Folien bitte als PDF auf USB Stick mitbringen. Lightning Talk Anmeldung bitte formlos per EMail an i...@pyddf.de KOSTENBETEILIGUNG Das Python Meeting Düsseldorf wird von Python Nutzern für Python Nutzer veranstaltet. Um die Kosten zumindest teilweise zu refinanzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von EUR 10,00 inkl. 19% Mwst, Schüler und Studenten zahlen EUR 5,00 inkl. 19% Mwst. Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen. ANMELDUNG Da wir nur für ca. 20 Personen Sitzplätze haben, möchten wir bitten, sich per EMail anzumelden. Damit wird keine Verpflichtung eingegangen. Es erleichtert uns allerdings die Planung. Meeting Anmeldung bitte formlos per EMail an i...@pyddf.de WEITERE INFORMATIONEN Weitere Informationen finden Sie auf der Webseite des Meetings: http://pyddf.de/ Mit freundlichen Grüßen, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 17 2013) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2013-07-01: EuroPython 2013, Florence, Italy ... 14 days to go 2013-07-16: Python Meeting Duesseldorf ... 29 days to go : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
[ANN] Django-debug-toolbar-template-timings
Django-debug-toolbar-template-timings version 0.4.1 has been released and can be found here: https://pypi.python.org/pypi/django-debug-toolbar-template-timings What is it? -- Does what it says on the tin. It's a panel for Django-debug-toolbar that breaks down the time it takes to render a template, showing detailed timing information for each sub-template and block. This helps you pinpoint exactly where the bottlekneck for your page is. More info and screenshots can be found here: https://github.com/orf/django-debug-toolbar-template-timings What's new in 0.4.1? -- * The sum, average, min and max execution time for each template and block is now recorded (thanks @twidi) * The total time spent rendering is displayed in the sidebar * Added options to ignore templates and print the timings to the console -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
ANNOUNCE: flufl.bounce 2.2
I am happy to announce flufl.bounce version 2.2. The flufl.bounce library provides a set of heuristics and an API for detecting the original bouncing email addresses from a bounce message. Many formats found in the wild are supported, as are VERP and RFC 3464 (DSN). flufl.bounce is the bounce detection library used by GNU Mailman. flufl.bounce is compatible with Python 2.6, 2.7, 3.2, and 3.3. My deep gratitude to Mark Sapiro for his help in preparing the 2.2 release. Thanks also to the other contributors named below. Here's what's new in version 2.2: * Added recognition for a bogus Dovecot over-quota rejection sent as an MDN rather than a DSN. (LP: #693134) * Tweaked a simplematch regexp that didn't always work. (LP: #1079254) * Added recognition for bounces from mail.ru. Thanks to Andrey Rahmatullin. (LP: #1079249) * Fixed UnicodeDecodeError in qmail.py with non-ascii message. Thanks to Theo Spears. (LP: #1074592) * Added recognition for another Yahoo bounce format. Thanks to Mark Sapiro. (LP: #1157961) * Fix documentation bug. (LP: #1026403) * Document the zope.interface requirement. (LP: #1021383) Full documentation is available here: http://pythonhosted.org/flufl.bounce/ The project home page is at: https://launchpad.net/flufl.bounce You can report bugs at: https://bugs.launchpad.net/flufl.bounce Download the package from the Cheeseshop: https://pypi.python.org/pypi/flufl.bounce Enjoy, -Barry -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]
On 06/19/2013 11:48 PM, Steven D'Aprano wrote: On Wed, 19 Jun 2013 23:16:51 -0600, Michael Torrie wrote: The real power and expressivity of Python comes from embracing the abstractions that Python provides to your advantage. There's a certain elegance and beauty that comes from such things, which I believe really comes from the elegance and beauty of LISP, some of which manages to shine forth in Python, despite its deficiencies. When I first learned Python, I was impressed that some of the elegance that I remember from Scheme (how to use lists as a basic type for example) was there, but in a form that appealed to me. Well said! Glad you made sense of it... the bit about LISP and Scheme came out a wee bit muddled. In fact thinking about it, perhaps LISPers would say about Python what a bible passage says about having the form of Godliness but denying the power thereof! For example, Python's lambda functions, and Python's functional programming capabilities in general. But since the LISP never really got a form beyond S-expressions, leaving us with lots of parenthesis everywhere, Python wins much as the Hitchhiker's Guide to the Galaxy wins. -- http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
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. ASCII: Supports exactly 127 code points, each of which takes up exactly 7 bits. Each code point represents a character. 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. 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: 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: A Beginner's Doubt
On Thu, Jun 20, 2013 at 1:31 AM, Rick Johnson rantingrickjohn...@gmail.com 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: class 'NameError':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: class 'NameError':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, 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: class 'NameError':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 antoon.par...@rece.vub.ac.be 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 somebody flames them. They may even find it
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 rantingrickjohn...@gmail.com 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 rustompm...@gmail.com 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 r...@panix.com wrote: In article 447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com, rusi rustompm...@gmail.com 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 c...@zip.com.au 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. snip 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 yanxiaopei...@gmail.com 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 joshua.landau...@gmail.com wrote: On 20 June 2013 04:11, Cameron Simpson c...@zip.com.au 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 c...@zip.com.au 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 rantingrickjohn...@gmail.com 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 rantingrickjohn...@gmail.com 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
rantingrickjohn...@gmail.com 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 russ.po...@gmail.com 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 ne...@norwich.edu wrote:
On 2013-06-20, Joshua Landau joshua.landau...@gmail.com wrote:
On 20 June 2013 04:11, Cameron Simpson c...@zip.com.au 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, wxjmfa...@gmail.com 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 rantingrickjohn...@gmail.com 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 rantingrickjohn...@gmail.com 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, wxjmfa...@gmail.com 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 pyt...@mrabarnett.plus.com wrote: On 20/06/2013 17:37, Chris Angelico wrote: On Fri, Jun 21, 2013 at 2:27 AM, wxjmfa...@gmail.com 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 rustompm...@gmail.com 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 ros...@gmail.com wrote: On Fri, Jun 21, 2013 at 3:12 AM, rusi rustompm...@gmail.com 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 ros...@gmail.com wrote:
On Fri, Jun 21, 2013 at 3:12 AM, rusi rustompm...@gmail.com 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 ian.g.ke...@gmail.com 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 module from pkg_resources import load_entry_point File /opt/TWWfsw/distribute06/lib/python27/pkg_resources.py, line 2709, in module 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 oscar.j.benja...@gmail.com wrote: | On 20 June 2013 04:11, Cameron Simpson c...@zip.com.au 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 c...@zip.com.au 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 ne...@norwich.edu wrote: | On 2013-06-20, Joshua Landau joshua.landau...@gmail.com wrote: | On 20 June 2013 04:11, Cameron Simpson c...@zip.com.au 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 c...@zip.com.au 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 rustompm...@gmail.com 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 steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 20 Jun 2013 09:19:48 -0400, Roy Smith wrote: In article 447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com, rusi rustompm...@gmail.com 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 the fundamental nature of
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:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE KMART SYSTEM my.dtd
LEVEL_1
LEVEL_2 ATTR=hello
ATTRIBUTE NAME=Property X VALUE =2/
/LEVEL_2
LEVEL_2 ATTR=goodbye
ATTRIBUTE NAME=Property Y VALUE =NULL/
LEVEL_3 ATTR=aloha
ATTRIBUTE NAME=Property X VALUE =3/
/LEVEL_3
ATTRIBUTE NAME=Property Z VALUE =welcome/
/LEVEL_2
/LEVEL_1
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 mailman.3647.1371777895.3114.python-l...@python.org, Tim Chase python.l...@tim.thechases.com 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 mailman.3647.1371777895.3114.python-l...@python.org, Tim Chase python.l...@tim.thechases.com 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 rantingrickjohn...@gmail.com 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 antoon.par...@rece.vub.ac.be 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 immersed in Python coding for 15 years? Well, if they are confused after 15 years i would
[issue18269] Clarify which integer is required in os.chmod() exception
New submission from anatoly techtonik: (type 'int', '0755') (type 'int', '0644') Traceback (most recent call last): File ./tools/bootstrap.py, line 185, in extract_zip os.fchmod(outfile, unixperm) TypeError: an integer is required Here the integer that is required is not `unixperm`, but `outfile`. -- assignee: docs@python components: Documentation messages: 191502 nosy: docs@python, techtonik priority: normal severity: normal status: open title: Clarify which integer is required in os.chmod() exception versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18269 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11016] Re-implementation of the stat module in C
Charles-François Natali added the comment: I still fail to understand why you just don't ditch the Python implementation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13483] Use VirtualAlloc to allocate memory arenas
Antoine Pitrou added the comment: I plan to test the Low Fragmentation Allocator, at least on Windows 7. I don't think it can be any better than raw mmap() / VirtualAlloc()... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18250] In itertools.repeat() object shadows object()
Antoine Pitrou added the comment: I don't think this is a problem, since it is only a local variable in a function. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13483] Use VirtualAlloc to allocate memory arenas
STINNER Victor added the comment: I plan to test the Low Fragmentation Allocator, at least on Windows 7. I don't think it can be any better than raw mmap() / VirtualAlloc()... I mean using the Low Fragmentation Allocator for PyObject_Malloc() instead of pymalloc. Martin wrote (msg148605): As an alternative approach, Python could consider completely dropping obmalloc on Windows, and using a Windows Low Fragementation Heap (LFH) instead, with HEAP_NO_SERIALIZE (as the heap would be protected by the GIL). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13483] Use VirtualAlloc to allocate memory arenas
Martin v. Löwis added the comment: Ok, I'm going to commit this patch. Any further revisions (including reversions) can be done then. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3329] API for setting the memory allocator used by Python
STINNER Victor added the comment: Update patch according to the last version of the PEP. -- Added file: http://bugs.python.org/file30653/py_setallocators-8.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18231] What's new in Python should explain what's new in UCD
Martin v. Löwis added the comment: I don't think anything of this is worth mentioning, except to mention the precise version number of the database. Anybody interested in the consequences of the change should read the announcement of the Unicode Consortium. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18234] Unicodedata module should provide access to codepoint aliases
Martin v. Löwis added the comment: I think the best way would be to provide a function unicodedata.aliases, returning a list of names for a given character or sequence. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18234 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4153] Unicode HOWTO up to date?
Roundup Robot added the comment: New changeset 1dbbed06a163 by Andrew Kuchling in branch '3.3': #4153: update Unicode howto for Python 3.3 http://hg.python.org/cpython/rev/1dbbed06a163 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4153 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16507] Patch selectmodule.c to support WSAPoll on Windows
Changes by Richard Oudkerk shibt...@gmail.com: -- keywords: +gsoc -patch resolution: - rejected stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16507 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16499] CLI option for isolated mode
Barry A. Warsaw added the comment: It applies cleanly, builds without noticeable problems and does what it's advertised to do. In other words, looks great to me! I say go for it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16499 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4153] Unicode HOWTO up to date?
A.M. Kuchling added the comment: As far as I can tell, there are no other outstanding suggestions for howto updates, so I'll now close this item. Feel free to re-open or file a new item if there are further improvements that can be made. -- resolution: - fixed stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4153 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9122] Problems with multiprocessing, Python embedding and Windows
Richard Oudkerk added the comment: We don't do non-security updates on Python 2.6 anymore. As a workaround you might be able to do something like import sys, multiprocessing sys.frozen = True# or multiprocessing.forking.WINEXE = True ... if __name__ == '__main__': multiprocessing.freeze_support() ... (I am not familiar with using Cython.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16499] CLI option for isolated mode
STINNER Victor added the comment: python -I and spython sound like two ways to get the same results. I would prefer to only have one way. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16499 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16499] CLI option for isolated mode
Barry A. Warsaw added the comment: On Jun 20, 2013, at 02:26 PM, STINNER Victor wrote: python -I and spython sound like two ways to get the same results. I would prefer to only have one way. Where does spython come from? Personally, I'd much rather this be an option on the existing python executable (i.e. `python -I`) than some other command. That makes it easier to discover and promote. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16499 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16499] CLI option for isolated mode
Christian Heimes added the comment: We don't have spython yet. Py_IsolatedFlag is also required if we ever going to have spython, too. We can always remove the command line flag before Python 3.4 hits beta. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16499 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18270] AttributeError: 'NoneType' object has no attribute 'interp'
New submission from Dennis Backhaus:
It just worked fine yesterday, but when I start IDLE (with and without trying
to open a file at the same time) I get this error.
Traceback (most recent call last):
File /Library/Frameworks/Python.framework/Versions/2.7/bin/idle, line 5, in
module
main()
File
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py,
line 1560, in main
shell.interp.runcommand(''.join((print(', tkversionwarning, '
AttributeError: 'NoneType' object has no attribute 'interp'
--
components: IDLE
messages: 191518
nosy: dbackhaus
priority: normal
severity: normal
status: open
title: AttributeError: 'NoneType' object has no attribute 'interp'
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18270
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6461] multiprocessing: freezing apps on Windows
Richard Oudkerk added the comment: I just tried freezing the program from multiprocessing import freeze_support,Manager if __name__ == '__main__': freeze_support() m=Manager() l = m.list([1,2,3]) l.append(4) print(l) print(repr(l)) using cx_Freeze with Python 2.7, and it worked fine: PS cxfreeze.bat foo.py copying C:\Python27\lib\site-packages\cx_Freeze\bases\Console.exe - C:\Tmp\dir\dist\foo.exe copying C:\Windows\system32\python27.dll - C:\Tmp\dir\dist\python27.dll writing zip file C:\Tmp\dir\dist\foo.exe ... PS dist\foo [1, 2, 3, 4] ListProxy object, typeid 'list' at 0x206f410 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6461 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11390] doctest: add cmdline parameters
R. David Murray added the comment: Here is a patch that implements the ones I'm interested in (-o for any option, and -f as a shortcut for -o FAIL_FAST). It's a good question whether doctest should support other unittest options, but doing so is more complicated than supporting -o and -f. Adding a couple people to nosy who have an interest in testing and doctest, hoping for a patch review :) -- keywords: +patch nosy: +barry, ezio.melotti, r.david.murray stage: needs patch - patch review versions: +Python 3.4 -Python 3.3 Added file: http://bugs.python.org/file30654/doctest_cli.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11390 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11390] doctest: add cmdline parameters
R. David Murray added the comment: Oh, a documentation update is still needed here, so I guess I'm not really ready for review yet :( -- stage: patch review - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11390 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16499] CLI option for isolated mode
Christian Heimes added the comment: It comes from Nick and http://www.python.org/dev/peps/pep-0432/ . Once PEP 432 is in place we can easily create variants of Python binaries with special flags. I'm in favor with python -I, too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16499 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18269] Clarify which integer is required in os.chmod() exception
Brett Cannon added the comment: os.chmod is implemented in posixmodule.c and the argument parsing code can be found at http://hg.python.org/cpython/file/3acbb23c73bc/Modules/posixmodule.c#l2605 . You will notice that the argument parsing is specified as Oi|$Op. That means the first argument is parsed as a Python object which is passed through a converter function and the second argument is required to be an integer. That converter function can be found at http://hg.python.org/cpython/file/3acbb23c73bc/Modules/posixmodule.c#l681. Looking at that code doesn't suggest that TypeError is raised with that message. What were the exact arguments you passed into os.chmod() that triggered the exception? -- assignee: docs@python - components: +Library (Lib) -Documentation nosy: +brett.cannon status: open - pending versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18269 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18270] AttributeError: 'NoneType' object has no attribute 'interp'
Amaury Forgeot d'Arc added the comment: PyShell.py, line 1541: if shell and cmd or script: Does it need parentheses? if shell and (cmd or script): -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18270 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17018] Inconsistent behaviour of methods waiting for child process
Changes by Richard Oudkerk shibt...@gmail.com: -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17018 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16499] CLI option for isolated mode
Nick Coghlan added the comment: CPython's startup sequence and collection of global flags are organically evolved madness, so I think adding even more complexity to them is a bad idea. When you're in a hole, the first thing to do is *stop digging*. I could use help laying the foundations for PEP 432 though - getting the separate Programs directory split out, breaking up the monstrosity that is pythonrun.c, etc. Implementing that basic refactoring in default will make it more feasible to keep the PEP branch up to date without major conflicts. On 21 Jun 2013 00:40, Christian Heimes rep...@bugs.python.org wrote: Christian Heimes added the comment: It comes from Nick and http://www.python.org/dev/peps/pep-0432/ . Once PEP 432 is in place we can easily create variants of Python binaries with special flags. I'm in favor with python -I, too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16499 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16499 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18271] get_payload method returns bytes which cannot be decoded using the message's charset
New submission from Marko Lalic:
When the message's Content-Transfer-Encoding is set to 8bit, the
get_payload(decode=True) method returns the payload encoded using
raw-unicode-escape. This means that it is impossible to decode the returned
bytes using the content charset obtained by the get_content_charset method.
It seems this should be fixed so that get_payload returns the bytes as found in
the payload when Content-Transfer-Encoding is 8bit, exactly like Python2.7
handles it.
from email import message_from_string
message = message_from_string(MIME-Version: 1.0
... Content-Type: text/plain; charset=utf-8
... Content-Disposition: inline
... Content-Transfer-Encoding: 8bit
...
... ünicöde data..)
message.get_content_charset()
'utf-8'
message.get_payload(decode=True)
b'\xfcnic\xf6de data..'
message.get_payload(decode=True).decode(message.get_content_charset())
Traceback (most recent call last):
File stdin, line 1, in module
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfc in position 0: invalid
start byte
message.get_payload(decode=True).decode('raw-unicode-escape')
'ünicöde data..'
--
components: email
messages: 191526
nosy: barry, mlalic, r.david.murray
priority: normal
severity: normal
status: open
title: get_payload method returns bytes which cannot be decoded using the
message's charset
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18271
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18122] RuntimeError: not holding the import lock
Richard Oudkerk added the comment: See also #9573 and #15914. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11390] doctest: add cmdline parameters
Changes by R. David Murray rdmur...@bitdance.com: Removed file: http://bugs.python.org/file30654/doctest_cli.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11390 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
