python3: 'module' object is not callable - type is class 'http.client.HTTPResponse'

2014-12-03 Thread Chris Cioffi
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

2014-12-03 Thread sravan kumar
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

2014-12-03 Thread Michael Kreim

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'

2014-12-03 Thread Chris Angelico
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

2014-12-03 Thread Sturla Molden
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'

2014-12-03 Thread Chris Angelico
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'

2014-12-03 Thread Tim Delaney
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

2014-12-03 Thread Kasper Peeters

 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'

2014-12-03 Thread Peter Otten
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'

2014-12-03 Thread Chris Angelico
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

2014-12-03 Thread Tim Chase
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

2014-12-03 Thread Chris Angelico
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

2014-12-03 Thread Tim Chase
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

2014-12-03 Thread Chris Angelico
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

2014-12-03 Thread Gregory Ewing

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.

2014-12-03 Thread Mark Lawrence

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.

2014-12-03 Thread Joshua Landau
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

2014-12-03 Thread Joshua Landau
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

2014-12-03 Thread Dave Angel

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?

2014-12-03 Thread Nobody
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.

2014-12-03 Thread mm0fmf

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.

2014-12-03 Thread sohcahtoa82
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?

2014-12-03 Thread Israel Brewster
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'

2014-12-03 Thread Ian Kelly
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'

2014-12-03 Thread Terry Reedy

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.

2014-12-03 Thread Peter Pearson
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.

2014-12-03 Thread Skybuck Flying



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.

2014-12-03 Thread Steven D'Aprano
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.

2014-12-03 Thread Chris Angelico
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

2014-12-03 Thread Dan Stromberg
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.

2014-12-03 Thread Joel Goldstick
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.

2014-12-03 Thread Mark Lawrence

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?

2014-12-03 Thread Aseem Bansal
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.

2014-12-03 Thread Michael Torrie
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?

2014-12-03 Thread Terry Reedy

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

2014-12-03 Thread Waldemar Parzonka

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

2014-12-03 Thread Greg Turner

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

2014-12-03 Thread Greg Turner

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

2014-12-03 Thread Greg Turner

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

2014-12-03 Thread Greg Turner

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

2014-12-03 Thread Kali Kaneko

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

2014-12-03 Thread Alex Gaynor

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

2014-12-03 Thread Antoine Pitrou

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`

2014-12-03 Thread Felipe

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`

2014-12-03 Thread Ethan Furman

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`

2014-12-03 Thread Guido van Rossum

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

2014-12-03 Thread Paul Hartmann

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`

2014-12-03 Thread R. David Murray

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

2014-12-03 Thread R. David Murray

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

2014-12-03 Thread Roundup Robot

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`

2014-12-03 Thread Ethan Furman

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

2014-12-03 Thread Antoine Pitrou

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`

2014-12-03 Thread Felipe

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`

2014-12-03 Thread Guido van Rossum

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

2014-12-03 Thread Matt Hansen

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

2014-12-03 Thread Jim Jewett

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

2014-12-03 Thread Demian Brecht

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

2014-12-03 Thread Chris Rebert

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

2014-12-03 Thread Antoine Pitrou

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

2014-12-03 Thread Mark Ingram

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

2014-12-03 Thread R. David Murray

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

2014-12-03 Thread Alan

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

2014-12-03 Thread Terry J. Reedy

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

2014-12-03 Thread Terry J. Reedy

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

2014-12-03 Thread Chris Rebert

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

2014-12-03 Thread Ezio Melotti

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

2014-12-03 Thread Xavier de Gaye

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

2014-12-03 Thread Demian Brecht

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

2014-12-03 Thread Ezio Melotti

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

2014-12-03 Thread Ned Deily

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

2014-12-03 Thread Josh Rosenberg

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

2014-12-03 Thread Berker Peksag

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

2014-12-03 Thread Nikolaus Rath

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

2014-12-03 Thread Nikolaus Rath

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

2014-12-03 Thread Greg Turner

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

2014-12-03 Thread Roundup Robot

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

2014-12-03 Thread Roundup Robot

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

2014-12-03 Thread Terry J. Reedy

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

2014-12-03 Thread Connor Wolf

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

2014-12-03 Thread Connor Wolf

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

2014-12-03 Thread Charles-François Natali

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

2014-12-03 Thread Ned Deily

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