python3: 'module' object is not callable - type is class 'http.client.HTTPResponse'
I'm writing a little script that uses a REST API and I'm having a problem using
urllib in Python 3.
I had the basics working in Python 2.7, but for reasons I'm not clear on I
decided to update to Python 3. (I'm in the early phases, so this isn't
production by any stretch.)
Python version info:
sys.version_info(major=3, minor=4, micro=2, releaselevel='final', serial=0)
Type() info of return object from urllib.request.urlopen:
class 'http.client.HTTPResponse'
Traceback of error when trying to pprint() the object:
Traceback (most recent call last):
File ./test.py, line 59, in module
testGetAvailableCash(lc)
File ./test.py, line 12, in testGetAvailableCash
print(lc.available_cash(INVESTORID, AUTHKEY))
File /Users/chris/dev/LendingClub/lendingclub.py, line 49, in available_cash
return self._make_api_call(''.join((BASE_ACCOUNT_URL, investorID,
/availablecash)), authorizationKey)[u'availableCash']
File /Users/chris/dev/LendingClub/lendingclub.py, line 40, in _make_api_call
pprint(lcresponse.read())
TypeError: 'module' object is not callable
The relevant code is as follows:
lcrequest = urllib.request.Request(url, data, {Authorization:
authorizationKey})
lcresponse = urllib.request.urlopen(lcrequest)
Any ideas on what I should be looking for? Based on the docs and examples I
would expect this to work.
Thanks!
Chris
--
https://mail.python.org/mailman/listinfo/python-list
Re: Looking for download link for ArcPY
Can I find where Arcpy.exe to download in order to use for my course work Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Python, C++ interaction
Hi, we are working on a small scientific program that helps us in developing and testing of new numerical methods for a certain type of biochemical problems. I spare you the math ;-) We code our new methods in Python and compare them with the existing methods. Unfortunately, these existing methods are quite slow and need a lot of runtime. Therefor we implemented them in C++. Now, we like to combine these two approaches. So we can develop a new method in Python and compare it easily with the results from the C++ functions. I did some googleing on extending Python by C++ code but I did not find something that satisfies me. I gave SWIG a try, but several webpages disadvised me of using it. Also my small experiments did not work. Now, I read about ctypes. But as far as I understood it, I have to write a C wrapper for my C++ code and then a Python wrapper for my C code. That seems a little complicated. My C++ code is structured as a class that contains several variables and functions. Then everything is compiled as a shared library. I can write things like: MyClass.initialvalue = 5; MyClass.timestep = 0.1; ... MyClass.solve(); I would like to keep this structure in python, but if I understand ctypes correctly I would loose the class approach. So after the long writeup I come to my questions: What are you using to wrap C++ classes for Python? Can you recommend swig? Should I give it another try? Did I misunderstood ctypes? Also later on in our code development we would like to pass python lambda functions to C++. So far I understood that this seems not to be possible. Do you have any ideas or hints on this topics? Thank you very much. Cheers, Michael -- https://mail.python.org/mailman/listinfo/python-list
Re: python3: 'module' object is not callable - type is class 'http.client.HTTPResponse'
On Tue, Dec 2, 2014 at 6:45 AM, Chris Cioffi ch...@evenprimes.com wrote:
File /Users/chris/dev/LendingClub/lendingclub.py, line 40, in
_make_api_call
pprint(lcresponse.read())
TypeError: 'module' object is not callable
The relevant code is as follows:
lcrequest = urllib.request.Request(url, data, {Authorization:
authorizationKey})
lcresponse = urllib.request.urlopen(lcrequest)
Any ideas on what I should be looking for? Based on the docs and examples I
would expect this to work.
Your problem isn't with urllib, but with pprint. The pprint module
exposes a function called pprint; you can use it either like this:
from pprint import pprint
pprint(some_object)
Or like this:
import pprint
pprint.pprint(some_object)
It looks like you're mixing and matching the two forms.
All the best!
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python, C++ interaction
Cython is nearly always the answer to scientific computing in Python, including wrapping C++. Sturla Michael Kreim mich...@perfect-kreim.de wrote: Hi, we are working on a small scientific program that helps us in developing and testing of new numerical methods for a certain type of biochemical problems. I spare you the math ;-) We code our new methods in Python and compare them with the existing methods. Unfortunately, these existing methods are quite slow and need a lot of runtime. Therefor we implemented them in C++. Now, we like to combine these two approaches. So we can develop a new method in Python and compare it easily with the results from the C++ functions. I did some googleing on extending Python by C++ code but I did not find something that satisfies me. I gave SWIG a try, but several webpages disadvised me of using it. Also my small experiments did not work. Now, I read about ctypes. But as far as I understood it, I have to write a C wrapper for my C++ code and then a Python wrapper for my C code. That seems a little complicated. My C++ code is structured as a class that contains several variables and functions. Then everything is compiled as a shared library. I can write things like: MyClass.initialvalue = 5; MyClass.timestep = 0.1; ... MyClass.solve(); I would like to keep this structure in python, but if I understand ctypes correctly I would loose the class approach. So after the long writeup I come to my questions: What are you using to wrap C++ classes for Python? Can you recommend swig? Should I give it another try? Did I misunderstood ctypes? Also later on in our code development we would like to pass python lambda functions to C++. So far I understood that this seems not to be possible. Do you have any ideas or hints on this topics? Thank you very much. Cheers, Michael -- https://mail.python.org/mailman/listinfo/python-list
Style question: Importing modules from packages - 'from' vs 'as'
When importing a module from a subpackage, it's sometimes convenient to refer to it throughout the code with a one-part name rather than two. I'm going to use 'os.path' for the examples, but my actual use-case is a custom package where the package name is, in the application, quite superfluous. Throughout the code, I want to refer to path.split(), path.isfile(), etc, without the os. in front of them. I could do either of these: import os.path as path from os import path Which one would you recommend? Does it depend on context? An as import works only if it's a module in a package, where the from import can also import other objects (you can't go import pprint.pprint as pprint). I'm fairly sure that's an argument... on one side or another. :) Thoughts? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On 3 December 2014 at 22:02, Chris Angelico ros...@gmail.com wrote: import os.path as path from os import path Bah - deleted the list and sent directly to Chris ... time to go to bed. The advantage of the former is that if you want to use a different name, it's a smaller change. But the disadvantage of the former is that if you *don't* want to rename, it violates DRY (don't repeat yourself). The difference is so marginal that I'd leave it to personal preference, and wouldn't pull someone up for either in a code review. Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: PyEval_GetLocals and unreferenced variables
I'm not sure how you think you're adding a local from C code. If you're using PyEval_GetLocals(), that only gives you a dict containing a *copy* of the locals; modifying that dict doesn't change the locals in the function's frame. That may have been the design plan, but in Python 2.7.6, I definitely am able to inject locals via PyEval_GetLocals() and have them be visible both from the C and Python side; see also http://stackoverflow.com/questions/22276502/create-python-object-in-local-scope-from-within-c If the bytecode of the nested function doesn't reference a given variable in the outer function, it doesn't get passed in. Ok, that's good to know because it rules out doing this without having an explicit reference to the variable in the inner scope. Thanks. Cheers, Kasper -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
Chris Angelico wrote: When importing a module from a subpackage, it's sometimes convenient to refer to it throughout the code with a one-part name rather than two. I'm going to use 'os.path' for the examples, but my actual use-case is a custom package where the package name is, in the application, quite superfluous. Throughout the code, I want to refer to path.split(), path.isfile(), etc, without the os. in front of them. I could do either of these: import os.path as path from os import path Which one would you recommend? Does it depend on context? Don't repeat yourself, so from os import path always. On the other hand I have never thought about actual renames, e. g. from os import path as stdpath versus import os.path as stdpath I think I'd use the latter as it looks simpler. An as import works only if it's a module in a package, where the from import can also import other objects (you can't go import pprint.pprint as pprint). I'm fairly sure that's an argument... on one side or another. :) In theory you could sometimes catch erroneous assumptions about pprint.pprint's type. But I don't care. -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On Wed, Dec 3, 2014 at 10:27 PM, Peter Otten __pete...@web.de wrote: Don't repeat yourself, so from os import path always. On the other hand I have never thought about actual renames, e. g. from os import path as stdpath versus import os.path as stdpath I think I'd use the latter as it looks simpler. Thanks, Peter and Tim. Keeping DRY is worth doing (the more so as it's raining as I type this...), and I won't be renaming in this, so the from-import wins - but as Tim says, it's a close race. I do like the turn-around times on this list. Although, of course, it's entirely possible there'll be a week's worth of posts coming when someone hits on a controversial subaspect of the question somewhere; any volunteers? :) :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new conditional operator: or else
On 2014-12-02 23:05, Dennis Lee Bieber wrote: foo == 42 or else Has a PERL stink to it... like: foo == 42 or die This actually works in Python and I occasionally use in debugging (much like -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new conditional operator: or else
On Wed, Dec 3, 2014 at 10:56 PM, Tim Chase python.l...@tim.thechases.com wrote: This actually works in Python and I occasionally use in debugging (much like finish_sentence() or die ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new conditional operator: or else
On 2014-12-02 23:05, Dennis Lee Bieber wrote: foo == 42 or else Has a PERL stink to it... like: foo == 42 or die This statement actually works in Python and I occasionally use it when debugging (in the same fashion as one might do printf() debugging in C). It raises a NameError and the program dies with a traceback. Most frequently, it's to prevent the program from continuing on to connect to a database and actually make changes. I've grown up a bit and usually use pdb.set_trace() now, but it's still in my grab-bag of tools. -tkc [sorry for the previous message if I failed to cancel the send that happened when I accidentally pressed ctrl+enter...typing in the dark] -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new conditional operator: or else
On Wed, Dec 3, 2014 at 10:59 PM, Tim Chase python.l...@tim.thechases.com wrote: On 2014-12-02 23:05, Dennis Lee Bieber wrote: foo == 42 or else Has a PERL stink to it... like: foo == 42 or die This statement actually works in Python and I occasionally use it when debugging (in the same fashion as one might do printf() debugging in C). It raises a NameError and the program dies with a traceback. Most frequently, it's to prevent the program from continuing on to connect to a database and actually make changes. *gasp* But it's just as fragile as assert! Anyone could just put one line of code into your program and destroy all your debugging checks! die = False Your code has just been made immortal! This is *obviously* a complete waste of time, since it's that easy to defeat! [sorry for the previous message if I failed to cancel the send that happened when I accidentally pressed ctrl+enter...typing in the dark] It was its own joke. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PyEval_GetLocals and unreferenced variables
Kasper Peeters wrote: That may have been the design plan, but in Python 2.7.6, I definitely am able to inject locals via PyEval_GetLocals() and have them be visible both from the C and Python side; What seems to be happening is that the dict created by PyEval_GetLocals() is kept around, so you can change it and have the changes be visible through locals() in Python. However, that doesn't create a local *name* that's visible from Python. Or if the local name exists, changes made through locals() aren't reflected in the value of the local name. Existing local name is not changed: def f(): ... a = 42 ... locals()['a'] = 17 ... print a ... f() 42 Can't create a local name: def g(): ... locals()['a'] = 17 ... print a ... g() Traceback (most recent call last): File stdin, line 1, in module File stdin, line 3, in g NameError: global name 'a' is not defined Changes to locals() persist: def h(): ... locals()['a'] = 17 ... print locals()['a'] ... h() 17 -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 03/12/2014 02:27, Skybuck Flying wrote: Excuse is: bad programming style. I don't need snot telling me how to program after 20 years of programming experience. This is so far the only thing pissing me off in python. Now I have to declare global in front of these variables every where I want to use em: Another example of a bad workman always blames his tools. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 3 December 2014 at 04:32, Skybuck Flying skybuck2...@hotmail.com wrote: I am still new at python and definetly don't feel comfortable with the object feature, though I did use it for these variables which are actually objects. If you are being serious, please take into consideration that there is no way you are going to convince anyone on this list with the way you are asking. For the most part, people will be convinced when you show them something that would improve *their* life, not something that would improve yours. Being an open-source project lead largely by volunteers, either you convince people on their terms or you go fork the project. To do the former, find an example in the standard library or some popular codebase and show how what you're suggesting could improve the code. If your example is good, you'll get support for the idea. If the example is bad, people will point out how better to approach this. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python, C++ interaction
On 3 December 2014 at 08:29, Michael Kreim mich...@perfect-kreim.de wrote: What are you using to wrap C++ classes for Python? Can you recommend swig? Should I give it another try? Did I misunderstood ctypes? The PyPy guys would love it if you used CFFI. Cython is also a wonderful approach. There's a lot of support of Cython, but it's also possible to find comparisons in CFFI's favour: http://eev.ee/blog/2013/09/13/cython-versus-cffi/ I've not actually used CFFI, but I've heard good things about it. Also later on in our code development we would like to pass python lambda functions to C++. So far I understood that this seems not to be possible. Do you have any ideas or hints on this topics? This is definitely possible. You'll need to build C++ against CPython and use the Python C API. I've personally found that Boost::Python simplified this dramatically and IMHO if most of your code needs to use Python types directly from C++ I'd scrap Cython altogether and just use Boost. Here's some stuff on callbacks with CFFI: https://cffi.readthedocs.org/en/release-0.5/#callbacks -- https://mail.python.org/mailman/listinfo/python-list
Re: Looking for download link for ArcPY
On 12/02/2014 05:48 PM, sravan kumar wrote: Can I find where Arcpy.exe to download in order to use for my course work I don't know the package. But it shouldn't be hard to find. Go to duckduckgo.com (or google, if that's your preference) type arcpy in the search box One of the result links is: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//000v000100 Take a look at argcis.com Or search for pypi arcpy https://pypi.python.org/pypi/arcpy_metadata/0.2.5 I don't know if that's exactly what you want, but there's plenty to browse around with. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
On Tue, 02 Dec 2014 21:41:33 +, John Gordon wrote: GET shouldn't cause any business data modifications, but I thought it was allowed for things like logging out of your session. GET isn't supposed to have observable side-effects. Observable excludes things like logs and statistics, but getting logged out of your session is definitely observable. X-moz: prefetch, X-Purpose etc (note that these all have X- prefixes, meaning that they're not in any standard) exist because web developers seem to be uniquely bad at distinguishing between specified behaviour and seems to work. But realistically, this horse is not only out of the barn but half way around the world by now. So many sites misuse GET that there has to be workarounds for it (to be honest, I'm surprised that they haven't made it into a standard yet). -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 03/12/2014 04:32, Skybuck Flying wrote: Some issues I'd like to address to you: 1. Structured programming requires more programming time. 2. Structured programming implies structure which might be less flexible. 3. Python objects require self keyword to be used everywhere, and other akwardness wich leads to more typing/programming/writing time. Hmm, I smell trolling! *plonk* -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Wednesday, December 3, 2014 10:05:06 AM UTC-8, mm0fmf wrote: On 03/12/2014 04:32, Skybuck Flying wrote: Some issues I'd like to address to you: 1. Structured programming requires more programming time. 2. Structured programming implies structure which might be less flexible. 3. Python objects require self keyword to be used everywhere, and other akwardness wich leads to more typing/programming/writing time. Hmm, I smell trolling! *plonk* I'm surprised other people haven't picked up on how obvious of a troll this Skybuck Flying guy is. He claims 20 years programming experience, then uses an absurd amount of globals, many of which are related, without using a data structure of some kind. I am still new at python and definetly don't feel comfortable with the object feature, Someone with 20 years of programming shouldn't have any problems understanding objects in Python. 20 years experience? Probably more like 20 minutes. -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
Ah, I see. That makes sense. Thanks. --- Israel Brewster Systems Analyst II Ravn Alaska 5245 Airport Industrial Rd Fairbanks, AK 99709 (907) 450-7293 --- BEGIN:VCARD VERSION:3.0 N:Brewster;Israel;;; FN:Israel Brewster ORG:Frontier Flying Service;MIS TITLE:PC Support Tech II EMAIL;type=INTERNET;type=WORK;type=pref:isr...@frontierflying.com TEL;type=WORK;type=pref:907-450-7293 item1.ADR;type=WORK;type=pref:;;5245 Airport Industrial Wy;Fairbanks;AK;99701; item1.X-ABADR:us CATEGORIES:General X-ABUID:36305438-95EA-4410-91AB-45D16CABCDDC\:ABPerson END:VCARD On Dec 2, 2014, at 9:17 PM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Israel Brewster wrote: Primary because they aren’t forms, they are links. And links are, by definition, GET’s. That said, as I mentioned in earlier replies, if using a form for a simple link is the Right Way to do things like this, then I can change it. I'd look at it another way and say that an action with side effects shouldn't appear as a simple link to the user. Links are for requesting information; buttons are for triggering actions. -- Greg -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On Dec 3, 2014 4:34 AM, Chris Angelico ros...@gmail.com wrote: On Wed, Dec 3, 2014 at 10:27 PM, Peter Otten __pete...@web.de wrote: Don't repeat yourself, so from os import path always. On the other hand I have never thought about actual renames, e. g. from os import path as stdpath versus import os.path as stdpath I think I'd use the latter as it looks simpler. Thanks, Peter and Tim. Keeping DRY is worth doing (the more so as it's raining as I type this...), and I won't be renaming in this, so the from-import wins - but as Tim says, it's a close race. To offer a counterpoint, the from import is also less explicit. With import os.path as path, path must be a module. With the from import, path could be either a module or just any attribute of the os module. My preference when importing modules is to use the fully qualified name -- os.path, not path. If I do a submodule import, I'm probably assigning a local name anyway, so I still prefer the import as over the from import as. -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On 12/3/2014 6:02 AM, Chris Angelico wrote: When importing a module from a subpackage, it's sometimes convenient to refer to it throughout the code with a one-part name rather than two. I'm going to use 'os.path' for the examples, but my actual use-case is a custom package where the package name is, in the application, quite superfluous. Throughout the code, I want to refer to path.split(), path.isfile(), etc, without the os. in front of them. I could do either of these: import os.path as path from os import path Which one would you recommend? Does it depend on context? I confirmed that they do the same thing for submodules. import os.path as pth from os import path pth module 'ntpath' from 'C:\\Programs\\Python34\\lib\\ntpath.py' path module 'ntpath' from 'C:\\Programs\\Python34\\lib\\ntpath.py' id(pth) 4319096 id(path) 4319096 I and most code I have seen uses from tkinter import ttk. An as import works only if it's a module in a package, where the from import can also import other objects (you can't go import pprint.pprint as pprint). I'm fairly sure that's an argument... on one side or another. import tkinter.ttk as ttk makes it clear that ttk is a module rather than, say, a class. That might make things easier for the reader. On the other hand, duplication implies that there might be a real renaming, so having to compare to see that there is not, is extra work. from idlelib import EditorWindow import idlelib.EditorWindow as EditorWindow -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Wed, 3 Dec 2014 03:27:45 +0100, Skybuck Flying wrote: I don't need snot telling me how to program after 20 years of programming experience. [snip] After 20 years of programming, I had a lot to learn about programming. That was 29 years ago, and I *still* have a lot to learn about programming. That's why I greatly enjoy this particular newsgroup. The last time I saw a stack of globals like that was in 1973. Program for driving a lathe. Didn't work. Best of luck to you. -- To email me, substitute nowhere-runbox, invalid-com. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Mark Lawrence wrote in message news:mailman.16534.1417610132.18130.python-l...@python.org... On 03/12/2014 02:27, Skybuck Flying wrote: Excuse is: bad programming style. I don't need snot telling me how to program after 20 years of programming experience. This is so far the only thing pissing me off in python. Now I have to declare global in front of these variables every where I want to use em: Another example of a bad workman always blames his tools. Euhm, so why don't you program with just 0 and 1's then ? ;) Bye, Skybuck :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
sohcahto...@gmail.com wrote: On Wednesday, December 3, 2014 10:05:06 AM UTC-8, mm0fmf wrote: On 03/12/2014 04:32, Skybuck Flying wrote: Some issues I'd like to address to you: 1. Structured programming requires more programming time. 2. Structured programming implies structure which might be less flexible. 3. Python objects require self keyword to be used everywhere, and other akwardness wich leads to more typing/programming/writing time. Hmm, I smell trolling! *plonk* I'm surprised other people haven't picked up on how obvious of a troll this Skybuck Flying guy is. He claims 20 years programming experience, then uses an absurd amount of globals, many of which are related, without using a data structure of some kind. 20 years of maintaining COBOL code first written in 1967 perhaps? Or more likely, VisualBasic. Skybuck Flying has posted here before: https://mail.python.org/pipermail/python-list/2013-October/657648.html Judging from what he considers good style and essential features of a programming language, I expect that he learned to program in BASIC back in the days of line numbers and GOTOs, and has barely adapted to a *slightly* more structured approach in VB. I am still new at python and definetly don't feel comfortable with the object feature, Someone with 20 years of programming shouldn't have any problems understanding objects in Python. Oh if that were only the case. It is amazing how long some people can work in a profession and still avoid learning anything new. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Thu, Dec 4, 2014 at 11:57 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Someone with 20 years of programming shouldn't have any problems understanding objects in Python. Oh if that were only the case. It is amazing how long some people can work in a profession and still avoid learning anything new. I heard that described as 1 year's experience gained 20 times. Sadly, some people have gained their first year of experience even more times than that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python, C++ interaction
On Wed, Dec 3, 2014 at 12:29 AM, Michael Kreim mich...@perfect-kreim.de wrote: Hi, I did some googleing on extending Python by C++ code but I did not find something that satisfies me. I gave SWIG a try, but several webpages disadvised me of using it. Also my small experiments did not work. Now, I read about ctypes. But as far as I understood it, I have to write a C wrapper for my C++ code and then a Python wrapper for my C code. That seems a little complicated. What are you using to wrap C++ classes for Python? Can you recommend swig? Should I give it another try? Did I misunderstood ctypes? Also later on in our code development we would like to pass python lambda functions to C++. So far I understood that this seems not to be possible. Do you have any ideas or hints on this topics? You've already received some good suggestions. I'll add that ctypes is a bit slow in CPython. Also, you might want to try one or more of the following before resorting to a less-productive language like C++: 1) writing in Cython+CPython (as opposed to wrapping C++ with Cython) 2) using numba+CPython (It's a pretty fast decorator - I've heard it's faster than Cython) 3) shedskin (translates implicitly static Python to C++) 4) pypy (Python with a JIT - ignore RPython) Here's a link I've been maintaining about ways of speeding up Python: http://stromberg.dnsalias.org/~strombrg/speeding-python/ HTH -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Wed, Dec 3, 2014 at 8:10 PM, Chris Angelico ros...@gmail.com wrote: On Thu, Dec 4, 2014 at 11:57 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Someone with 20 years of programming shouldn't have any problems understanding objects in Python. Oh if that were only the case. It is amazing how long some people can work in a profession and still avoid learning anything new. I heard that described as 1 year's experience gained 20 times. Sadly, some people have gained their first year of experience even more times than that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list I especially liked the 'phython' reference in his post from 2013! -- Joel Goldstick http://joelgoldstick.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 03/12/2014 23:02, Skybuck Flying wrote: Mark Lawrence wrote in message news:mailman.16534.1417610132.18130.python-l...@python.org... On 03/12/2014 02:27, Skybuck Flying wrote: Excuse is: bad programming style. I don't need snot telling me how to program after 20 years of programming experience. This is so far the only thing pissing me off in python. Now I have to declare global in front of these variables every where I want to use em: This reminds of of a quote from a colleague some 25 years ago Real time programming is easy, you just make all the data global. Perhaps you attended the same school? Another example of a bad workman always blames his tools. Euhm, so why don't you program with just 0 and 1's then ? ;) I did with the M6800 in the late 70s. Thankfully maybe 12 years ago I came across Python and it was love at first sight. I've never looked back. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Is Python installer/un-installer buggy on Windows?
I am using 32-bit Python on a 64-bit Windows. Edit with IDLE is missing from the context menu. I am working on Windows 7. I have searched on google a lot and have tried everything said in superuser, stackoverflow etc. I have even tried re-installing Python. I am now only left with re-installing Windows itself which I don't think is a good idea. Shouldn't the Python installer be able to fix this thing? I have both Python 2.7 and 3.4 installed but I uninstalled both and tried installing one. No use. Is there some problem with Python (un-)installer on Windows? I am asking because I have multiple IDLE in my Start menu one of which starts to install Python 3.3 in the default location (which I had earlier). -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 12/03/2014 08:57 PM, Dennis Lee Bieber wrote: On Wed, 3 Dec 2014 10:16:18 -0800 (PST), sohcahto...@gmail.com declaimed the following: I'm surprised other people haven't picked up on how obvious of a troll this Skybuck Flying guy is. He claims 20 years programming experience, then uses an absurd amount of globals, many of which are related, without using a data structure of some kind. My initial impression is of 20 years of KemenyKurtz BASIC... Of the 70s... with everything global. BASIC was slow in changing, that's for sure. I have used BASIC a lot over the years, and it's been highly structured with modern scoping rules since about the mid 80s. Certainly Borland's Turbo BASIC provided real functions and subroutines, private variables, block structures, etc. Sadly BASIC dialects tended to try to maintain backwards compatibility so even modern dialects like FreeBASIC can be coerced into executing spaghetti code. Sad that the OP is stuck in this style of programming. Whatever works for him. Maybe instead of Python he should use FreeBASIC with the -lang qb flag. Actually, more appropriate might be PC Basic [1] which is a GW BASIC clone actually written in Python. Nothing better than executing spaghetti code in an interpreter written in an interpreted language! Python indeed must be powerful indeed. [1] http://sourceforge.net/projects/pcbasic -- https://mail.python.org/mailman/listinfo/python-list
Re: Is Python installer/un-installer buggy on Windows?
On 12/3/2014 10:16 PM, Aseem Bansal wrote: I am using 32-bit Python on a 64-bit Windows. Edit with IDLE is missing from the context menu. I am working on Windows 7. I have searched on google a lot and have tried everything said in superuser, stackoverflow etc. I have even tried re-installing Python. I suspect the problem is with the registry. Only one version of Python/Idle can be connected to that entry. I am now only left with re-installing Windows itself which I don't think is a good idea. Definitely not. Shouldn't the Python installer be able to fix this thing? I have both Python 2.7 and 3.4 installed but I uninstalled both and tried installing one. No use. Did you check [x] make default version, whatever the exact wording is? How did you uninstall, and reinstall? Is there some problem with Python (un-)installer on Windows? Occasionally. asking because I have multiple IDLE in my Start menu one of which starts to install Python 3.3 in the default location (which I had earlier). I do not understand how a Start menu entry can begin an installation. It is the result of installation. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
[issue22983] Cookie parsing should be more permissive
Changes by Waldemar Parzonka waldemar.parzo...@gmail.com: -- nosy: +Waldemar.Parzonka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype
Greg Turner added the comment: Just added a commit message. -- Added file: http://bugs.python.org/file37349/fix_types_calculate_meta_v3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22968 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype
Greg Turner added the comment: Here are some tests for this... first, some tests that pass right now and demonstrate, I think, correctness of the second batch of tests. -- Added file: http://bugs.python.org/file37350/test_virtual_metaclasses.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22968 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype
Greg Turner added the comment: And some analogous tests for types.py, which don't pass without fix_types_calculate_meta_v3.patch. -- Added file: http://bugs.python.org/file37351/test_virtual_metaclasses_in_types_module.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22968 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype
Greg Turner added the comment: And some analogous tests for types.py, which don't pass without fix_types_calculate_meta_v3.patch. -- Added file: http://bugs.python.org/file37352/test_virtual_metaclasses_in_types_module.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22968 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22987] ssl module documentation: incorrect compatibility matrix
New submission from Kali Kaneko: The SSLv23 row that can be read in the socket creation section in the documentation for the ssl module looks incorrect: https://docs.python.org/2.7/library/ssl.html#socket-creation by my tests (with python 2.7.8) that row should read: yes no yes yes yes yes instead of: yes no yes no no no as it does now. Since a client specifying SSLv23 should be (and it seems to be) able to negotiate the highest available version that the server can offer, no matter if the server has chosen a tls version. Is this an error in the documentation, or is there any situation in which the current values hold true? -- assignee: docs@python components: Documentation messages: 232078 nosy: docs@python, kali priority: normal severity: normal status: open title: ssl module documentation: incorrect compatibility matrix versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22987] ssl module documentation: incorrect compatibility matrix
Alex Gaynor added the comment: I agree this is a bug, but I believe the correct output is: no yes yes yes yes yes -- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22987] ssl module documentation: incorrect compatibility matrix
Antoine Pitrou added the comment: Alex is right. The current doc was valid for older OpenSSL versions, which sent a SSLv2 hello with SSLv23. Reference from the OpenSSL docs: If the cipher list does not contain any SSLv2 ciphersuites (the default cipher list does not) or extensions are required (for example server name) a client will send out TLSv1 client hello messages including extensions and will indicate that it also understands TLSv1.1, TLSv1.2 and permits a fallback to SSLv3. A server will support SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols. (https://www.openssl.org/docs/ssl/SSL_CTX_new.html) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
New submission from Felipe: This bug report is the opposite of issue #14718. The interpreter did not raise an error when it encountered a `yield` expression inside the `finally` part of a `try/finally` statement. My system's info: Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)] on win32 More detail === My interpreter does not raise any errors when yielding from a `finally` block. The documentation states, Yield expressions are allowed in the try clause of a try ... finally construct.[1] Though not explicitly stated, the suggestion is that `yield` is not allowed in the `finally` clause. Issue #14718 suggests that this interpretation is correct. Not raising an exception for `yield` inside of `finally` can cause incorrect behavior when the generator raises its own unhandled exception in the `try` block. PEP 342 says, If the generator raises an uncaught exception, it is propagated to send()'s caller. In this case, however, the exception gets paused at the `yield` expression, instead of propagating to the caller. Here's an example that can clarify the issue: def f(): # I expected this function not to compile ... try: ... raise ValueError ... finally: ... yield 1 # Execution freezes here instead of propagating the ValueError ... yield done ... g = f() g.send(None) # PEP 342 would require ValueError to be raised here 1 g.send(1) Traceback (most recent call last): File stdin, line 1, in module File stdin, line 3, in f2 ValueError I may be arguing over the meaning of uncaught exception, but I expected (given that the function compiles and doesn't raise a `RuntimeError`) the `ValueError` to propagate rather than get frozen. Example 2 --- The second example is adapted from http://bugs.python.org/issue14718, where the submitter received a `RuntimeError`, but I did not: def f2(): # I also expected this function not to compile ... try: ... yield 1 ... finally: ... yield 4 ... g = f() # issue 14718 suggests this should raise RuntimeError next(g) 1 next(g) 4 next(g) Traceback (most recent call last): File stdin, line 1, in module StopIteration Possible resolution: = 1. Enforce the ban on `yield` inside a finally `clause`. It seems like this should already be happening, so I'm not sure why my version isn't performing the check. This could be a run-time check (which seems like it may already be implemented), but I think this could even be a compile-time check (by looking at the AST). 2. Clarify the documentation to make explicit the ban on the use of `yield` inside the `finally` clause, and specify what type of error it will raise (i.e., `SyntaxError` or `RuntimeError`? or something else?). I'll submit a patch for 2 if there's support for this change, and I will work on 1 if someone can point me in the right direction. I've engaged with the C source relating to the different protocols, but have never looked through the compiler/VM. Notes [1] https://docs.python.org/3.4/reference/expressions.html#yield-expressions -- components: Interpreter Core messages: 232081 nosy: fov priority: normal severity: normal status: open title: No error when yielding from `finally` type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
Guido van Rossum added the comment: There is no prohibition in the language against yield in a finally block. It may not be a good idea, but the behavior you see is all as it should be. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22989] HTTPResponse.msg not as documented
New submission from Paul Hartmann:
HTTPResponse.msg is documented as a http.client.HTTPMessage object containing
the headers of the response [1].
But in fact this is a string containing the status code:
import urllib.request
req=urllib.request.urlopen('http://heise.de')
content = req.read()
type(req.msg)
class 'str'
req.msg
'OK'
This value is apparently overriden in urllib/request.py:
./urllib/request.py:1246:# This line replaces the .msg attribute of the
HTTPResponse
./urllib/request.py-1247-# with .headers, because urllib clients expect
the response to
./urllib/request.py:1248:# have the reason in .msg. It would be good
to mark this
./urllib/request.py-1249-# attribute is deprecated and get then to use
info() or
./urllib/request.py-1250-# .headers.
./urllib/request.py:1251:r.msg = r.reason
Anyhow, it should be documented, that is not safe to retrieve the headers with
HTTPResponse.msg and maybe add HTTPResponse.headers to the documentation.
[1] https://docs.python.org/3/library/http.client.html
--
assignee: docs@python
components: Documentation
messages: 232083
nosy: bastik, docs@python
priority: normal
severity: normal
status: open
title: HTTPResponse.msg not as documented
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22989
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
R. David Murray added the comment: FIlipe, in case you hadn't noticed, the reason for the error in the other issue is that the generator was closed when it got garbage collected, and it ignored the close (executed a yield after the close). Thus the error message there is accurate and expected, just as (as Guido said) the behavior here is consistent with the combined semantics of generators and try/finally. Do you want to suggest an improvement to the docs? It may be that we'll decide a change is more confusing than helpful, but we'll need someone to suggest a wording to decide that. -- assignee: - docs@python components: +Documentation -Interpreter Core nosy: +docs@python, r.david.murray versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22989] HTTPResponse.msg not as documented
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22989 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22987] ssl module documentation: incorrect compatibility matrix
Roundup Robot added the comment: New changeset 7af5d5493497 by Antoine Pitrou in branch '2.7': Fix #22987: update the compatibility matrix for a SSLv23 client. https://hg.python.org/cpython/rev/7af5d5493497 New changeset 9f03572690d2 by Antoine Pitrou in branch '3.4': Fix #22987: update the compatibility matrix for a SSLv23 client. https://hg.python.org/cpython/rev/9f03572690d2 New changeset 7509a0607c40 by Antoine Pitrou in branch 'default': Fix #22987: update the compatibility matrix for a SSLv23 client. https://hg.python.org/cpython/rev/7509a0607c40 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
Ethan Furman added the comment: Here's the excerpt from the docs: Yield expressions are allowed in the try clause of a try ... finally construct. If the generator is not resumed before it is finalized (by reaching a zero reference count or by being garbage collected), the generator-iterator’s close() method will be called, allowing any pending finally clauses to execute. This certainly makes it sound like 'yield' is okay in the 'try' portion, but not the 'finally' portion. So 'yield' is allowed in the 'try' portion, and it's allowed in the 'finally' portion -- is it also allowed in the 'except' portion? If so, we could simplify the first line to: Yield expressions are allowed in try ... except ... finally constructs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22987] ssl module documentation: incorrect compatibility matrix
Changes by Antoine Pitrou pit...@free.fr: -- resolution: - fixed stage: - resolved status: open - closed versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
Felipe added the comment: Thanks for the clarification; sorry I misread issue #14718. I agree with Ethan's point. Though I would say Yield expressions are allowed anywhere in try ... except ... finally constructs. I'd also like to explicitly add a point about the exception-handling machinery getting frozen, but I'm not sure how to phrase it clearly and accurately. Here's an attempt (my adds in square brackets): By suspended, we mean that all local state is retained, including the current bindings of local variables, the instruction pointer, the internal evaluation stack, [active exception handlers, and paused exceptions in finally blocks]. Another approach would be: By suspended, we mean that all local state is retained, including the current bindings of local variables, the instruction pointer, and the internal evaluation stack. [The state of any exception-handling code is also retained when yielding from a try ... except ... finally statement.] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
Changes by Guido van Rossum gu...@python.org: -- nosy: -gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22988 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11101] plistlib has no graceful way of handing None values
Changes by Matt Hansen hanse...@me.com: -- nosy: +Matt.Hansen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11101 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16329] mimetypes does not support webm type
Jim Jewett added the comment: I interpreted Issue 15's closure as being about the distinction between Application/webm vs Video/webm, etc. As far as I understand it, the python stdlib doesn't actually care what the major Mime type is, or, frankly, even whether the definition makes sense. We just want Video/webm to be registered. I have created issue 886 on the webm site at https://code.google.com/p/webm/issues/detail?id=886can=4colspec=ID%20Pri%20mstone%20ReleaseBlock%20Type%20Component%20Status%20Owner%20Summary Anyone with more detail (e.g., do we need to define Application/webm as well as Video/webm ... do we care what the definition is ... etc ...) is encouraged to chime in. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21557] os.popen os.system lack shell-related security warnings
Demian Brecht added the comment: After discussion in Rietveld, the patch looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21557 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16329] mimetypes does not support webm type
Chris Rebert added the comment: WebM's docs use video/webm and never use an application/* type. See http://www.webmproject.org/docs/container/ They also specify audio/webm for audio-only content, but both use the same file extension, so associating .webm with video/webm seems quite reasonable since it's more general (an audio-only file is just a degenerate case of an audiovideo file). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22982] BOM incorrectly inserted before writing, after seeking in text file
Antoine Pitrou added the comment: This is a limitation more than a bug. When you seek to the start of the file, the encoder is reset because Python thinks you are gonna to write there. If you remove the call to `file.seek(0, io.SEEK_SET)`, things work fine. @Amaury, whence can only be zero there: https://hg.python.org/cpython/file/0744ceb5c0ed/Lib/_pyio.py#l1960 -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22982] BOM incorrectly inserted before writing, after seeking in text file
Mark Ingram added the comment: It's more than a limitation, because if I call `file.seek(0, io.SEEK_END)` then the encoder is still reset, and will still write the BOM, even at the end of the file. This also means that it's impossible to seek in a text file that you want to append to. I've had to work around this by opening the file as binary, manually writing the BOM, and writing the strings as encoded bytes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21557] os.popen os.system lack shell-related security warnings
R. David Murray added the comment: Since Raymond is the person who tends to object most strongly to warning boxes in the docs, let's get his opinion on this. I'm not sure that the warning box is necessary, the text may be sufficient. On the other hand, this *is* a significant insecurity vector. As far as the text goes, I'd combine the two paragraphs and introduce the text from the second one with Alternatively, And if it isn't a warning box, the the language should be refocused to be positive: Use the Popen module with shell=False to avoid the common security issues involved in using unsanitized input from untrusted sources... -- nosy: +r.david.murray, rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21557 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22990] bdist installation dialog
New submission from Alan: The Select Python Installations dialog box contains the line Select the Python locations where distribution_name should be installed. If distribution_name is anything other than a very short string, the line is truncated, due to the following factors: - the line doesn't wrap - the dialog box can't be resized - the message (aside from the distribution name) is fairly lengthy See the screenshot, where I created a distribution of a package whose name is not_such_a_long_name. At the same time as the line is made wrappable and/or the dialog box is made resizable, it would be nice to improve the wording of the message. It took me a while to figure out what was going on because the GUI elements have different meanings from the ones seen more commonly. Usually these elements (the menu with choices beginning with Will be installed on local hard drive and ending with Entire feature will be unavailable) are used to choose one or more features of an application to install, not one or more places to install the same application. Maybe something like this would work: Select Where to Install Select Python locations in which to install distribution_name: Python 2.7 (found in the registry) Python 3.3 (found in the registry) Python (other location) instead of the current: Select Python Installations Select the Python locations where distribution_name should be installed: Python 2.7 from registry Python 3.3 from registry Python from another location -- components: Distutils files: bdist_screenshot.PNG messages: 232094 nosy: Alan, dstufft, eric.araujo priority: normal severity: normal status: open title: bdist installation dialog type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file37353/bdist_screenshot.PNG ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16329] mimetypes does not support webm type
Terry J. Reedy added the comment: Antoine Pitrou and Ethan Furman agreed on pydev that this should be applied. Chris, is the existing patch exactly what you think is needed? -- nosy: +terry.reedy stage: - commit review type: - enhancement versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16329] mimetypes does not support webm type
Terry J. Reedy added the comment: Does test_mimetypes (assuming it exists), have a test for the mapping, are is something needed? -- stage: commit review - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16329] mimetypes does not support webm type
Chris Rebert added the comment: Yes, the existing patch looks fine. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16329] mimetypes does not support webm type
Ezio Melotti added the comment: A while ago there was a discussion about updating the MIME registry on bug fix releases too, and I seem to remember people agreed it should be done. If this is indeed the case and the patch is accepted for 3.5, should it also be backported to 2.7 and 3.4? -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22991] test_gdb leaves the terminal in raw mode with gdb 7.8.1
New submission from Xavier de Gaye: This happens on archlinux. Annoying: the terminal becomes unusable unless you type blindly 'stty sane CTL-J', and the backspace key is still wrong. This does not happen with gdb 7.6.1. And this does not happen when running gdb with the 'mi' interpreter. The attached patch uses GDB/MI. The problem with using the GDB/MI interface, is that it is very verbose when trying to debug a test. -- components: Tests files: gdbmi.patch keywords: patch messages: 232099 nosy: xdegaye priority: normal severity: normal status: open title: test_gdb leaves the terminal in raw mode with gdb 7.8.1 type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file37354/gdbmi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22991 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22992] Adding a git developer's guide to Mercurial to devguide
New submission from Demian Brecht: Coming out of a recent thread in python-dev, it was mentioned that adding a git developer's guide to mercurial may be beneficial to help lower the initial barrier of entry for prospective contributors (https://mail.python.org/pipermail/python-dev/2014-November/137280.html). The attached patch is a slightly reworded version of my blog post here: http://demianbrecht.github.io/vcs/2014/07/31/from-git-to-hg/. -- components: Devguide files: gitdevs.patch keywords: patch messages: 232100 nosy: demian.brecht, ezio.melotti priority: normal severity: normal status: open title: Adding a git developer's guide to Mercurial to devguide Added file: http://bugs.python.org/file37355/gitdevs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22992 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22992] Adding a git developer's guide to Mercurial to devguide
Ezio Melotti added the comment: I have a few comments about the patch. About the markup: 1) you can specify the default highlight (bash) once at the top of the file, and just use :: afterwards instead of .. code-block::; 2) the used for some headers is inconsistent with the other files; 3) when you use NamedBranches, do you want to create a link? if so you should use :ref:`NamedBranches` and add a reference; About the content: 1) you should make clear that bookmarks are local and they won't be included in the patch and/or affect the main repo; 2) we usually want a single diff for each issue -- you should show how to create a diff that includes all the changes related to issueA or issueB (this can be done easily with named branches, not sure about bookmarks); 3) hg ci --amend could be used to update existing changesets after a review (this will also solve the above problem); 4) it should be possible to use evolve instead of bookmarks, but evolve is currently still a work in progress, so I'm not sure is worth mentioning it yet; 5) you said that named branches, bookmarks, and queues are all branches types in Mercurial. Can you add a source for that? (I never heard of bookmarks and queues as branches, but they might be, and there are also non-named branches. I just want to make sure that the terms are used correctly.); 6) when you mention :code:`hg log -G`, you should probably mention -L10 too, otherwise on the CPython repo the command will result in a graph with 90k+ changesets; 7) Note that Mercurial doesn't have git's concept of staging, so all changes will be committed. - To avoid committing there are different ways: a) leave the code uncommitted in the working copy (works with one or two unrelated issues, but doesn't scale well); b) save changes on a .diff and apply it when needed (what I usually do, scales well but it has a bit of overhead since you need to update/apply the diff); c) use mq; d) use evolve. Mercurial also has the concept of phases (http://mercurial.selenic.com/wiki/Phases) that might be somewhat related, even though it affected committed changes (if you set a cs as secret it won't be pushed); 8) Trying to learn usual hg workflows might also be easier than trying to use a git-like workflow on mercurial, so you could suggest considering them too (I don't remember if we have anything about it in the devguide though). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22992 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22991] test_gdb leaves the terminal in raw mode with gdb 7.8.1
Changes by Ned Deily n...@acm.org: -- nosy: +dmalcolm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22991 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20692] Tutorial and FAQ: how to call a method on an int
Changes by Josh Rosenberg shadowranger+pyt...@gmail.com: -- nosy: +josh.r ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20692 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22992] Adding a git developer's guide to Mercurial to devguide
Berker Peksag added the comment: +The workflow of a developer might look something like this: a core developer or a contributor? It would be good to split core developer and contributor workflows. +# address review comments and merge +git checkout master +git merge issueA +git branch -d issueA For example, from the contributor side, you shouldn't touch the master branch at all. It should be: # address review comments git commit -a # check upstream and rebase git pull --rebase upstream master # or origin master in this example # push changes (optional) git push origin issueA # origin should be contributor's fork here -- nosy: +berker.peksag stage: - patch review type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22992 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17852] Built-in module _io can loose data from buffered files at exit
Changes by Nikolaus Rath nikol...@rath.org: -- nosy: +nikratio ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17852 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17852] Built-in module _io can loose data from buffered files at exit
Nikolaus Rath added the comment: Serhiy, I believe this still happens in Python 3.4, but it is harder to reproduce. I couldn't get Armin's script to produce the problem either, but I'm pretty sure that this is what causes e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771452#60. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17852 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype
Greg Turner added the comment: Fixed a trivial typo in test_virtual_metaclass_in_types_module.patch -- versions: +Python 3.5 Added file: http://bugs.python.org/file37356/test_virtual_metaclasses_in_types_module_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22968 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16893] Generate Idle help from Doc/library/idle.rst
Roundup Robot added the comment: New changeset 6db65ff985b6 by Terry Jan Reedy in branch '3.4': Issue #16893: For Idle doc, move index entries, copy no-subprocess section https://hg.python.org/cpython/rev/6db65ff985b6 New changeset feec1ea55127 by Terry Jan Reedy in branch '2.7': Issue #16893: Update 2.7 version of Idle doc to match 3.4 doc as of the just https://hg.python.org/cpython/rev/feec1ea55127 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16893 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3068] IDLE - Add an extension configuration dialog
Roundup Robot added the comment: New changeset 395673aac686 by Terry Jan Reedy in branch '2.7': Issue #3068: Document the new Configure Extensions dialog and menu entry. https://hg.python.org/cpython/rev/395673aac686 New changeset b099cc290ae9 by Terry Jan Reedy in branch '3.4': Issue #3068: Document the new Configure Extensions dialog and menu entry. https://hg.python.org/cpython/rev/b099cc290ae9 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3068] IDLE - Add an extension configuration dialog
Changes by Terry J. Reedy tjre...@udel.edu: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22993] Plistlib fails on certain valid plist values
New submission from Connor Wolf:
I'm using plistlib to process plist files produced by an iphone app. Somehow,
the application is generating plist files with a absolute date value along the
lines of `-12-30T00:00:00Z`.
This is a valid date, and the apple plist libraries can handle this without
issue. However, it causes a ValueError if you load a plist containing it.
Minimal example:
python file:
```
import plistlib
test = plistlib.readPlist('./test.plist')
```
plist file:
```
?xml version=1.0 encoding=UTF-8?
!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN
http://www.apple.com/DTDs/PropertyList-1.0.dtd;
plist version=1.0
dict
keyTest/key
date-12-30T00:00:00Z/date
/dict
/plist
```
This fails on both python3 and python2, with the exact same error:
```
herp@mainnas:/media/Storage/Scripts/pFail$ python3 test.py
Traceback (most recent call last):
File test.py, line 3, in module
test = plistlib.readPlist('./test.plist')
File /usr/lib/python3.4/plistlib.py, line 164, in readPlist
dict_type=_InternalDict)
File /usr/lib/python3.4/plistlib.py, line 995, in load
return p.parse(fp)
File /usr/lib/python3.4/plistlib.py, line 325, in parse
self.parser.ParseFile(fileobj)
File /usr/lib/python3.4/plistlib.py, line 337, in handle_end_element
handler()
File /usr/lib/python3.4/plistlib.py, line 413, in end_date
self.add_object(_date_from_string(self.get_data()))
File /usr/lib/python3.4/plistlib.py, line 291, in _date_from_string
return datetime.datetime(*lst)
ValueError: year is out of range
herp@mainnas:/media/Storage/Scripts/pFail$ python test.py
Traceback (most recent call last):
File test.py, line 3, in module
test = plistlib.readPlist('./test.plist')
File /usr/lib/python2.7/plistlib.py, line 78, in readPlist
rootObject = p.parse(pathOrFile)
File /usr/lib/python2.7/plistlib.py, line 406, in parse
parser.ParseFile(fileobj)
File /usr/lib/python2.7/plistlib.py, line 418, in handleEndElement
handler()
File /usr/lib/python2.7/plistlib.py, line 474, in end_date
self.addObject(_dateFromString(self.getData()))
File /usr/lib/python2.7/plistlib.py, line 198, in _dateFromString
return datetime.datetime(*lst)
ValueError: year is out of range
herp@mainnas:/media/Storage/Scripts/pFail$
```
--
components: Library (Lib)
messages: 232107
nosy: Connor.Wolf
priority: normal
severity: normal
status: open
title: Plistlib fails on certain valid plist values
type: behavior
versions: Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22993
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22993] Plistlib fails on certain valid plist values
Connor Wolf added the comment: Aaaand there is no markup processing. How do I edit my report? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17852] Built-in module _io can loose data from buffered files at exit
Charles-François Natali added the comment: Serhiy, I believe this still happens in Python 3.4, but it is harder to reproduce. I couldn't get Armin's script to produce the problem either, but I'm pretty sure that this is what causes e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771452#60. Maybe, as it's been said several times, it's an application bug: files should be closed explicitly (or better with a context manager of course). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17852 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22993] Plistlib fails on certain valid plist values
Ned Deily added the comment: (Currently, it is not possible to edit a particular message in an issue. You could add a replacement comment to the issue and ask that the older message be delete.) This seems to be a problem date. As documented, plistlib converts plist dates to/from Python datetime.datetime objects. And, as is documented from datetime objects, the year field must be between 1 (MINYEAR) and (MAXYEAR). So, it would appear that dates with year 0 are not representable as datetime objects; it's not obvious to me how plistlib could handle a date like that without changing the API, i.e. returning something other than a datetime object or by changing the rules for datetime objects, which is very unlikely to happen. https://docs.python.org/dev/library/plistlib.html https://docs.python.org/dev/library/datetime.html#datetime.MINYEAR -- nosy: +belopolsky, ned.deily, ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
