Re: help for using Python rsa

On Sat, Feb 7, 2015 at 4:14 PM, wrote: > encrypted massage is like this: > "@\xc4\xb2\x14r\xf1x\xb8\xb2\t;\x9a:\x1dl\x11\xe2\x10\xa9E\xee\x8b\xac\xd0\xd3Y\xfb}\xd9@\xdd\x0c\xa5\xd2\xfc1\xd6\x06\xf0\xb8\x944\xe1\xc2r\xe5anyq\xac\xdfh\xeb\x10\x80\x98\xa1\xee'\xe6hpi" > > and i know it should be lik

Re: help for using Python rsa

On 02/07/2015 12:14 AM, mhr1...@gmail.com wrote: I use this code to create public and private keys: import rsa (pubkey, privkey) = rsa.newkeys(512) And then convert it to PEM format: exppub =pubkey.save_pkcs1(format='PEM') exppriv = privkey.save_pkcs1(format='

Re: Incompatible idioms: relative imports, top-level program file

On Saturday, February 7, 2015 at 8:43:44 AM UTC+5:30, Rustom Mody wrote: > There is on the one hand python modules/packages mechanism with all the > hell of dozens of incompatible versions of setuptools/distribute/distutils > etc. > > On the other there is the OS-specific practices/policy such a

help for using Python rsa

I use this code to create public and private keys: import rsa (pubkey, privkey) = rsa.newkeys(512) And then convert it to PEM format: exppub =pubkey.save_pkcs1(format='PEM') exppriv = privkey.save_pkcs1(format='PEM') When i encrypt massage with this keys: m

Re: Incompatible idioms: relative imports, top-level program file

On Saturday, February 7, 2015 at 7:35:12 AM UTC+5:30, Ben Finney wrote: > Ethan Furman writes: > > > On 02/06/2015 04:44 PM, Ben Finney wrote: > > > A program will often have enough complexity that its implementation > > > occupies several sub-modules. There's no need to explose those in a > > >

Re: Matplotlib import error

In article , C Smith wrote: > I had python 2.7.6 installed on OS X yosemite, which has always worked > fine, until I tried to install matplotlib with pip. I got the same > error below and upgraded to 2.7.9, used pip to upgrade all the > packages, but still get the same error. > > >>> import mat

Re: Incompatible idioms: relative imports, top-level program file

Ethan Furman writes: > On 02/06/2015 04:44 PM, Ben Finney wrote: > > A program will often have enough complexity that its implementation > > occupies several sub-modules. There's no need to explose those in a > > site package, they normally only need to be local to the > > application. > > If the

Re: Incompatible idioms: relative imports, top-level program file

On 02/06/2015 04:44 PM, Ben Finney wrote: > Ethan Furman writes: > >> On 02/06/2015 02:56 PM, Ben Finney wrote: >>> It is a deliberate design decision that direct import of a module >>> makes that module blind to its location in the package hierarchy. >>> >>> That's a design decision I deplore, b

Incompatible idioms: relative imports, top-level program file (was: Setuptools, __init__ and __main__)

Ethan Furman writes: > On 02/06/2015 02:56 PM, Ben Finney wrote: > > It is a deliberate design decision that direct import of a module > > makes that module blind to its location in the package hierarchy. > > > > That's a design decision I deplore, because it makes something that > > should be e

Re: Setuptools, __init__ and __main__

On 02/06/2015 06:56 PM, Steven D'Aprano wrote: Dave Angel wrote: And don't name any source code __main__.py, That's incorrect. Starting from Python 2.6, __main__.py is reserved for the application main script in packages. That is, if you design your application as a package (not a single fi

Re: Setuptools, __init__ and __main__

Dave Angel wrote: > And don't name any source code __main__.py, That's incorrect. Starting from Python 2.6, __main__.py is reserved for the application main script in packages. That is, if you design your application as a package (not a single file) with this structure: myapplication/ +-- __i

Re: Monte Carlo probability calculation in Python

Paul Moore wrote: > On Thursday, 5 February 2015 23:02:42 UTC, Paul Moore wrote: >> Nice! Thanks both of you. I start to see how to think about these >> things now. I'll play around with some of the other examples I've got, >> and see how far I get. > > Just a quick status update, in case you'

Re: Setuptools, __init__ and __main__

On 02/06/2015 02:56 PM, Ben Finney wrote: > > It's not Setuptools per se, it's Python's import mechanism. It is a > deliberate design decision that direct import of a module makes that > module blind to its location in the package hierarchy. > > That's a design decision I deplore, because it make

Re: Setuptools, __init__ and __main__

On Friday, 6 February 2015 22:20:58 UTC, Rob Gaddi wrote: > I found a recommendation at https://chriswarrick.com/blog/2014/09/15/ > python-apps-the-right-way-entry_points-and-scripts/ that seems to say > that I should get around this by simply having an empty __init__. I > guess I can move the

Re: Setuptools, __init__ and __main__

Rob Gaddi writes: > So, I'll take the app I'm working on right now as an example. I've got > 348 lines in my __init__.py, and another 200 in another library. > Little baby program. By “another library”, I think you mean “another module”. I'll assume that in the rest of this response. > My libra

Re: Monte Carlo probability calculation in Python

On Thursday, 5 February 2015 23:02:42 UTC, Paul Moore wrote: > Nice! Thanks both of you. I start to see how to think about these > things now. I'll play around with some of the other examples I've got, > and see how far I get. Just a quick status update, in case you're interested. With relativel

Re: Setuptools, __init__ and __main__

On 02/06/2015 02:20 PM, Rob Gaddi wrote: > > My library code isn't in __init__.py (or previously in __main__) because > I'm trying to dodge recursive imports; it's there because the code is > short enough and tightly-coupled enough that I didn't see upside in > splitting any of it out to a sepa

Re: Setuptools, __init__ and __main__

On Fri, 06 Feb 2015 16:44:26 -0500, Dave Angel wrote: > On 02/06/2015 04:35 PM, Ben Finney wrote: >> Rob Gaddi writes: >> >>> So I'm trying to wrap my head around packaging issues >> >> Congratulations on tackling this. You will likely find the Python >> Packaging User Guide https://packaging.pyt

Re: Setuptools, __init__ and __main__

On 02/06/2015 04:35 PM, Ben Finney wrote: Rob Gaddi writes: So I'm trying to wrap my head around packaging issues Congratulations on tackling this. You will likely find the Python Packaging User Guide https://packaging.python.org/> helpful. Also know that Python packaging was in a terrible

Re: Setuptools, __init__ and __main__

Rob Gaddi writes: > So I'm trying to wrap my head around packaging issues Congratulations on tackling this. You will likely find the Python Packaging User Guide https://packaging.python.org/> helpful. Also know that Python packaging was in a terrible state for a long stretch of years, but now t

Setuptools, __init__ and __main__

So I'm trying to wrap my head around packaging issues, and according to some quick Google searches I'm not the only one. I'm developing applications of various size for internal deployment. When I'm actually getting the whole thing written, I've got my initialization stub in __main__.py, becau

Re: Matplotlib import error

On 06/02/2015 19:02, Ian Kelly wrote: On Fri, Feb 6, 2015 at 11:49 AM, C Smith wrote: On Fri, Feb 6, 2015 at 10:20 AM, Chris Angelico wrote: On Sat, Feb 7, 2015 at 3:34 AM, C Smith wrote: ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nump

Re: Matplotlib import error

On Fri, Feb 6, 2015 at 11:49 AM, C Smith wrote: > On Fri, Feb 6, 2015 at 10:20 AM, Chris Angelico wrote: >> On Sat, Feb 7, 2015 at 3:34 AM, C Smith wrote: >>> ImportError: >>> dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so, >>> 2

Re: Matplotlib import error

On Fri, Feb 6, 2015 at 10:20 AM, Chris Angelico wrote: > On Sat, Feb 7, 2015 at 3:34 AM, C Smith wrote: >> ImportError: >> dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so, >> 2): Symbol not found: __gfortran_compare_string > > Ah,

Re: help with pypeg2?

Ian Kelly wrote: > On Fri, Feb 6, 2015 at 7:55 AM, Neal Becker wrote: >> Trying out pypeg2. The below grammar is recursive. A 'Gen' is an ident >> followed by parenthesized args. args is a csl of alphanum or Gen. >> >> The tests 'p' and 'p2' are fine, but 'p3' fails >> SyntaxError: expecting u

Re: Matplotlib import error

On Sat, Feb 7, 2015 at 3:34 AM, C Smith wrote: > ImportError: > dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so, > 2): Symbol not found: __gfortran_compare_string Ah, installing from source on a Mac and having problems. Have I hear

Re: help with pypeg2?

On Fri, Feb 6, 2015 at 7:55 AM, Neal Becker wrote: > Trying out pypeg2. The below grammar is recursive. A 'Gen' is an ident > followed by parenthesized args. args is a csl of alphanum or Gen. > > The tests 'p' and 'p2' are fine, but 'p3' fails > SyntaxError: expecting u')' > > > from __future__

Matplotlib import error

I had python 2.7.6 installed on OS X yosemite, which has always worked fine, until I tried to install matplotlib with pip. I got the same error below and upgraded to 2.7.9, used pip to upgrade all the packages, but still get the same error. >>> import matplotlib Traceback (most recent call last):

Re: Usage of some pastebin service proposed

On 2015-02-05, Abhiram R wrote: > I've noticed a lot of people enquiring about syntactic errors and email > somewhat butchers the indentation every now and then Just use a non-broken email program. -- Grant Edwards grant.b.edwardsYow! Are we laid back yet?

help with pypeg2?

Trying out pypeg2. The below grammar is recursive. A 'Gen' is an ident followed by parenthesized args. args is a csl of alphanum or Gen. The tests 'p' and 'p2' are fine, but 'p3' fails SyntaxError: expecting u')' from __future__ import unicode_literals, print_function from pypeg2 import * i

Re: meaning of: line, =

On Friday, February 6, 2015 at 6:40:23 PM UTC+5:30, Devin Jeanpierre wrote: > Sorry for late reply, I somehow missed this email. > > On Thu, Feb 5, 2015 at 8:59 AM, Rustom Mody wrote: > > The reason I ask: I sorely miss haskell's pattern matching in python. > > > > It goes some way: > > > ((x

Re: meaning of: line, =

On Friday, February 6, 2015 at 6:40:23 PM UTC+5:30, Devin Jeanpierre wrote: > Sorry for late reply, I somehow missed this email. > > On Thu, Feb 5, 2015 at 8:59 AM, Rustom Mody wrote: > > The reason I ask: I sorely miss haskell's pattern matching in python. > > > > It goes some way: > > > ((x

Re: meaning of: line, =

Sorry for late reply, I somehow missed this email. On Thu, Feb 5, 2015 at 8:59 AM, Rustom Mody wrote: > The reason I ask: I sorely miss haskell's pattern matching in python. > > It goes some way: > ((x,y),z) = ((1,2),3) x,y,z > (1, 2, 3) > > But not as far as I would like: > ((x,y)

Re: Booksigning Party at PyCon This Year!

Well dear, in my opinion attire should be according to the occasion and wedding reception is a special day for couple. And every couple wants that their guests love the event. Rest is up to you my friend. -- View this message in context: http://python.6.x6.nabble.com/B

PyDev 3.9.2 Released

What is PyDev? --- PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and IronPython development. It comes with goodies such as code completion, syntax highlighting, syntax analysis, code analysis, refactor, debug, interactive console, etc. Details on

Re: multiprocessing.Queue() and missing sem_open

On Fri, Feb 6, 2015 at 7:27 PM, Оlе Ѕtrеісhеr wrote: >> the AttributeError will come from the attribute lookup - the above code >> can't[1] bomb out with ImportError. > > Maybe it can't but it actually does. Huh. Okay, my bad. (I don't have a Hurd system to test on, all my Debians are Linux.) Sor

Re: multiprocessing.Queue() and missing sem_open

Chris Angelico writes: > On Fri, Feb 6, 2015 at 7:22 AM, Оlе Ѕtrеісhеr wrote: >> I am just trying to prepare a package (astropy) for (Debian) Hurd. This >> os lacks a sem_open() implementation. When I now try: >> >> import multiprocessing >> q = multiprocessing.Queue() >> >> I get an ImportError

Re: pymongo and attribute dictionaries

On Thu, Feb 5, 2015 at 6:27 AM, Anssi Saari wrote: > What I find surprising is that so many people cling so hard to their > localized keyboard layouts. I think none of those were created by > engineers and should be avoided by technical people. Or, in fact, > everyone. Even Microsoft seems to unde