Re: pymongo and attribute dictionaries

[Ian Kelly]

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 understand this and so Windows
> installs the US English layout by default as an alternative.

Speaking as a user of both Dvorak and Qwerty, switching between
layouts frequently can be confusing. In particular the pain points are
the places where the two layouts are similar. I haven't done this so
much recently, but in the past I have often been typing away in one
layout, then come to an A or an M (which happen to be in the same
position in both layouts) at which point my brain would inadvertently
"switch" and I would suddenly find myself typing in the wrong layout.
I would expect that a localized layout with more similarity than what
there is between Dvorak and Qwerty would cause even more of these
types of problems.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: multiprocessing.Queue() and missing sem_open

[Оlе Ѕtrеісhеr]

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 with Python 2.7, but an AttributeError with Python
>> 3.4. In the documentation of multiprocessing.Queue() I couldn't find any
>> hint that it would throw this exception.
>
> Neither of those errors is being consciously thrown by the Queue
> class; the latter means that multiprocessing exists but it has no
> Queue in it, and the former means that the entire multiprocessing
> module is absent.

Trace with 3.4.2:

self = , maxsize = 0

def Queue(self, maxsize=0):
'''Returns a queue object'''
from .queues import Queue
>   return Queue(maxsize, ctx=self.get_context())

/usr/lib/python3.4/multiprocessing/context.py:101: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = , maxsize = 0

def __init__(self, maxsize=0, *, ctx):
if maxsize <= 0:
>   maxsize = _multiprocessing.SemLock.SEM_VALUE_MAX
E   AttributeError: 'module' object has no attribute 'SemLock'

/usr/lib/python3.4/multiprocessing/queues.py:38: AttributeError

Trace with 2.7.9:

maxsize = 0

def Queue(maxsize=0):
'''
Returns a queue object
'''
>   from multiprocessing.queues import Queue

/usr/lib/python2.7/multiprocessing/__init__.py:217: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

__all__ = ['Queue', 'SimpleQueue', 'JoinableQueue']

import sys
import os
import threading
import collections
import time
import atexit
import weakref

from Queue import Empty, Full
import _multiprocessing
from multiprocessing import Pipe
>   from multiprocessing.synchronize import Lock, BoundedSemaphore, Semaphore, 
> Condition

/usr/lib/python2.7/multiprocessing/queues.py:48: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

'Lock', 'RLock', 'Semaphore', 'BoundedSemaphore', 'Condition', 'Event'
]

import threading
import os
import sys

from time import time as _time, sleep as _sleep

import _multiprocessing
from multiprocessing.process import current_process
from multiprocessing.util import Finalize, register_after_fork, debug
from multiprocessing.forking import assert_spawning, Popen

# Try to import the mp.synchronize module cleanly, if it fails
# raise ImportError for platforms lacking a working sem_open implementation.
# See issue 3770
try:
from _multiprocessing import SemLock
except (ImportError):
raise ImportError("This platform lacks a functioning sem_open" +
  " implementation, therefore, the required" +
  " synchronization primitives needed will not" +
> " function, see issue 3770.")
E ImportError: This platform lacks a functioning sem_open 
implementation, therefore, the required synchronization primitives needed will 
not function, see issue 3770.

/usr/lib/python2.7/multiprocessing/synchronize.py:59: ImportError

Both are with the same Hurd version.

> I'm guessing you built Python from source?

No, I am using the precompiled version that comes with Debian. It has no
specific patch for sem_open.

> But this is the exact way that Python will normally signal that
> something isn't available. If your platform doesn't have, say,
> os.O_BINARY, because that flag has no meaning for you, then you don't
> get NotImplementedError - you simply get AttributeError.

As you can see from the trace, multiprocessing.Queue is there, but
initialization fails.

>> Can I be sure that the following works also in future?
>>
>> try
>> q = multiprocessing.Queue()
>> except (ImportError, AttributeError)
>> # handle the case of missing sem_open
>>
>> Or what is the correct way to catch a not working Queue caused by a
>> missing sem_open() implementation?
>
> The ImportError will come from the import statement

No.

> 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.

> So a more correct way would be something like:
>
> try:
> import multiprocessing
> multiprocessing.Queue
> except (ImportError, AttributeError):
> # handle the absence

Is it sure that this will work in the future as well?

> Or alternatively, don't even bother to try/except the import. If your
> code requires multiprocessing.Queue (as opposed to just queue.Queue),
> chances are you can't cope with the absence of the module.

This code is used for a fast, asynchronious reader. If it is not
implemented, there is a (slower) fallback solution. However, we just want
to catch the "is not implemented" case here but

Re: multiprocessing.Queue() and missing sem_open

[Chris Angelico]

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.) Sorry for the misinformation.

>> So a more correct way would be something like:
>>
>> try:
>> import multiprocessing
>> multiprocessing.Queue
>> except (ImportError, AttributeError):
>> # handle the absence
>
> Is it sure that this will work in the future as well?

Frankly, I don't know now. It's reasonably likely that it will, but in
the absence of actual documentation, I couldn't say.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

PyDev 3.9.2 Released

[Fabio Zadrozny]

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 PyDev: http://pydev.org
Details on its development: http://pydev.blogspot.com


What is LiClipse?
---

LiClipse is a PyDev standalone with goodies such as support for Multiple
cursors, theming and a number of other languages such as Django Templates,
Kivy Language, Mako Templates, Html, Javascript, etc.

It's also a commercial counterpart which helps supporting the development
of PyDev.

Details on LiClipse: http://www.liclipse.com/


Release Highlights:
---

* **Important**: PyDev requires Eclipse 3.8 or 4.3 onwards and Java 7! For
older versions, keep using PyDev 2.x (use LiClipse: http://www.liclipse.com
for a PyDev standalone with all requirements bundled).

* **PyVmMonitor Integration**

* PyVmMonitor: http://www.pyvmmonitor.com/ is now in public beta, so, the
PyDev integration
(Window > Show View > Other > PyDev > Profile) may be used to  profile your
programs.

* **Debugger**

* The debug view now has an interactive console (with history) attached to
it by default (which may be toggled on/off). (PyDev-507)
* Debugger no longer reopens a file when that file is already opened.
(PyDev-456)
* Handled issue when getting referrers for some object gave an error if it
was found in a dict where the key is not a string.
* When interactive console starts in debug session, a banner is no longer
shown.
* Stepping with #@DontTrace no longer returns through decorator call-site.
(PyDev-526)
* The default for tracing template render exceptions on Django is now false.

* **Interactive Console**

* F2 to send contents from editor to console now considers backslash
continuations. (PyDev-502)
* Interactive Console interrupt now properly interrupts a sleep call (when
possible). (PyDev-500)
* PyDev interactive console now has a user-specified encoding (by default
UTF-8). (PyDev-454)
* Scroll the console on stdout / stderr output. (PyDev-504, patch by James
Blackburn)
* Moved interactive console initial commands to a separate preferences page.
* Handling interrupted system call EINTR in the pydevconsole.py. (PyDev-534)
* Fixed racing condition where the output of the console could appear as a
user input. (PyDev-490, patch by James Blackburn)

* **Refactoring**

* Fixed issue where indentation lost on rename module refactoring.
(PyDev-498)
* The rename modules refactoring wizard now provides a way to do a simple
resource rename (to rename extensions).

* **Others**

* Converting filename from .pyx to .py doesn't loose indexing on the file
anymore. (PyDev-525)
* The Cython parser now properly scopes methods.
* Pasting contents directly in the PyDev package explorer to create a file
uses the proper delimiter.
* Fixed deadlock in ImageCache when rendering debug completions from
console. (PyDev-527)
* Fixed deadlock on racing condition when rendering PyTextHover. (PyDev-523)
* Tab settings were separated from the editor color settings and may now be
persisted in the project/user settings.
* Fixed surround with try..finally/except indentation on Ctrl+1 when some
line has a comment which has a different indentation.


Cheers,

--
Fabio Zadrozny
--
Software Developer

LiClipse
http://www.liclipse.com

PyDev - Python Development Environment for Eclipse
http://pydev.org
http://pydev.blogspot.com

PyVmMonitor - Python Profiler
http://www.pyvmmonitor.com/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Booksigning Party at PyCon This Year!

[Jocel23]

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/Booksigning-Party-at-PyCon-This-Year-tp935988p5085422.html
Sent from the Python - python-list mailing list archive at Nabble.com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: meaning of: line, =

[Devin Jeanpierre]

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),3) = ((1,2),3)
>   File "", line 1
> SyntaxError: can't assign to literal

>
> [Haskell]
>
> Prelude> let (x, (y, (42, z, "Hello"))) = (1, (2, (42, 3, "Hello")))
> Prelude> (x,y,z)
> (1,2,3)

Yeah, but Haskell is ludicrous.

Prelude> let (x, 2) = (1, 3)
Prelude>

Only non-falsifiable patterns really make sense as the left hand side
of an assignment in a language without exceptions, IMO. Otherwise you
should use a match/case statement. (Of course, Python does have
exceptions...)

-- Devin
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: meaning of: line, =

[Rustom Mody]

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,y),z) = ((1,2),3)
>  x,y,z
> > (1, 2, 3)
> >
> > But not as far as I would like:
> >
>  ((x,y),3) = ((1,2),3)
> >   File "", line 1
> > SyntaxError: can't assign to literal
> 
> >
> > [Haskell]
> >
> > Prelude> let (x, (y, (42, z, "Hello"))) = (1, (2, (42, 3, "Hello")))
> > Prelude> (x,y,z)
> > (1,2,3)
> 
> Yeah, but Haskell is ludicrous.
> 
> Prelude> let (x, 2) = (1, 3)
> Prelude>
> 
> Only non-falsifiable patterns really make sense as the left hand side
> of an assignment in a language without exceptions, IMO. Otherwise you
> should use a match/case statement.

Which is what people do 99% of the times - write pattern matching function defs

I was just writing a 1 liner showing matching of constants and variables 
simultaneously
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: meaning of: line, =

[Rustom Mody]

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,y),z) = ((1,2),3)
>  x,y,z
> > (1, 2, 3)
> >
> > But not as far as I would like:
> >
>  ((x,y),3) = ((1,2),3)
> >   File "", line 1
> > SyntaxError: can't assign to literal
> 
> >
> > [Haskell]
> >
> > Prelude> let (x, (y, (42, z, "Hello"))) = (1, (2, (42, 3, "Hello")))
> > Prelude> (x,y,z)
> > (1,2,3)
> 
> Yeah, but Haskell is ludicrous.
> 
> Prelude> let (x, 2) = (1, 3)
> Prelude>
> 
> Only non-falsifiable patterns really make sense as the left hand side
> of an assignment in a language without exceptions, IMO. Otherwise you
> should use a match/case statement. (Of course, Python does have
> exceptions...)

Also its good to see the full context of your example:

Prelude> let (x, 2) = (1, 3)
Prelude> x
*** Exception: :2:5-19: Irrefutable pattern failed for pattern (x, 
2)

Prelude> 


So I am not sure what you find ludicrous.
Haskell is a lazy language. 
This is lazy behavior. What else can it be?

[Does not make me a great fan of laziness -- which is another matter]
-- 
https://mail.python.org/mailman/listinfo/python-list

help with pypeg2?

[Neal Becker]

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 *

ident = re.compile (r'[a-z]+')
alphanum = re.compile (r'[a-z0-9]+')
num = re.compile (r'[0-9]+')

class args (List):
grammar = maybe_some ( csl ([alphanum, Gen]))

class Gen (List):
grammar = attr ('type', ident), '(', attr ('args', args), ')'

p = parse ('abc,123', args)
p2 = parse ('abc(123,456)', Gen)
p3 = parse ('abc(123,def(456))', Gen)

-- 
-- Those who don't understand recursion are doomed to repeat it

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Usage of some pastebin service proposed

[Grant Edwards]

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?
  at   
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Matplotlib import error

[C Smith]

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):
  File "", line 1, in 
  File "/Library/Python/2.7/site-packages/matplotlib/__init__.py",
line 180, in 
from matplotlib.cbook import is_string_like
  File "/Library/Python/2.7/site-packages/matplotlib/cbook.py", line
33, in 
import numpy as np
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/__init__.py",
line 170, in 
from . import add_newdocs
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/add_newdocs.py",
line 13, in 
from numpy.lib import add_newdoc
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/__init__.py",
line 18, in 
from .polynomial import *
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/polynomial.py",
line 19, in 
from numpy.linalg import eigvals, lstsq, inv
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/linalg/__init__.py",
line 51, in 
from .linalg import *
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/linalg/linalg.py",
line 29, in 
from numpy.linalg import lapack_lite, _umath_linalg
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
  Referenced from:
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so
  Expected in: flat namespace
 in 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: help with pypeg2?

[Ian Kelly]

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__ import unicode_literals, print_function
> from pypeg2 import *
>
> ident = re.compile (r'[a-z]+')
> alphanum = re.compile (r'[a-z0-9]+')
> num = re.compile (r'[0-9]+')
>
> class args (List):
> grammar = maybe_some ( csl ([alphanum, Gen]))

I'm not familiar with pypeg2, but should this use optional instead of
maybe_some? The csl function already produces a list, so the result of
maybe_some on that would be one or more consecutive lists.

Also, it looks from the docs like it should just be "csi(alphanum,
Gen)" (no list in the arguments).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Matplotlib import error

[Chris Angelico]

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 heard
this story before? Just occasionally? It's almost as if the platform
is actively hostile toward C and Fortran...

But I found this at the far end of a Google search. Maybe it'll help?

http://stackoverflow.com/questions/22080154/error-importing-numpy-after-upgrading-with-pip

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: help with pypeg2?

[Neal Becker]

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')'
>>
>>
>> from __future__ import unicode_literals, print_function
>> from pypeg2 import *
>>
>> ident = re.compile (r'[a-z]+')
>> alphanum = re.compile (r'[a-z0-9]+')
>> num = re.compile (r'[0-9]+')
>>
>> class args (List):
>> grammar = maybe_some ( csl ([alphanum, Gen]))
> 
> I'm not familiar with pypeg2, but should this use optional instead of
> maybe_some? The csl function already produces a list, so the result of
> maybe_some on that would be one or more consecutive lists.
> 
> Also, it looks from the docs like it should just be "csi(alphanum,
> Gen)" (no list in the arguments).

It didn't work without [list..] (even trivial examples did not work without it).
I don't know if it's broken, I though csl (*args) should mean a comma-sep-list 
of _any_ of the *args, but it doesn't work.  [list] means alternatives, and 
does 
seem to work (for simple examples).

-- 
-- Those who don't understand recursion are doomed to repeat it

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Matplotlib import error

[C Smith]

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, installing from source on a Mac and having problems. Have I heard
> this story before? Just occasionally? It's almost as if the platform
> is actively hostile toward C and Fortran...
>
> But I found this at the far end of a Google search. Maybe it'll help?
>
> http://stackoverflow.com/questions/22080154/error-importing-numpy-after-upgrading-with-pip
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list

I already had gcc installed and had used it to build other packages.
It worked in the past when clang was throwing errors. I tried making
the symlink from the stackoverflow question, but still get the same
errors. I will look around and see if I can find if gcc is even being
used by pip properly. I really regret not using virtual environments
from day one. Lesson learned the hard way, I guess. Thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Matplotlib import error

[Ian Kelly]

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): Symbol not found: __gfortran_compare_string
>>
>> Ah, installing from source on a Mac and having problems. Have I heard
>> this story before? Just occasionally? It's almost as if the platform
>> is actively hostile toward C and Fortran...
>>
>> But I found this at the far end of a Google search. Maybe it'll help?
>>
>> http://stackoverflow.com/questions/22080154/error-importing-numpy-after-upgrading-with-pip
>>
>> ChrisA
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>
> I already had gcc installed and had used it to build other packages.
> It worked in the past when clang was throwing errors. I tried making
> the symlink from the stackoverflow question, but still get the same
> errors. I will look around and see if I can find if gcc is even being
> used by pip properly. I really regret not using virtual environments
> from day one. Lesson learned the hard way, I guess. Thanks

With numpy and non-Linux platforms, I find it saves a lot of pain to
just install a binary distribution.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Matplotlib import error

[Mark Lawrence]

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/numpy/linalg/lapack_lite.so,
2): Symbol not found: __gfortran_compare_string


Ah, installing from source on a Mac and having problems. Have I heard
this story before? Just occasionally? It's almost as if the platform
is actively hostile toward C and Fortran...

But I found this at the far end of a Google search. Maybe it'll help?

http://stackoverflow.com/questions/22080154/error-importing-numpy-after-upgrading-with-pip

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list


I already had gcc installed and had used it to build other packages.
It worked in the past when clang was throwing errors. I tried making
the symlink from the stackoverflow question, but still get the same
errors. I will look around and see if I can find if gcc is even being
used by pip properly. I really regret not using virtual environments
from day one. Lesson learned the hard way, I guess. Thanks


With numpy and non-Linux platforms, I find it saves a lot of pain to
just install a binary distribution.



Regardless of numpy this site http://www.lfd.uci.edu/~gohlke/pythonlibs/ 
is a must know about for Windows users.  Is there anything like it for 
the Mac?


--
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

Setuptools, __init__ and __main__

[Rob Gaddi]

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, because it's an application rather 
than a library.  But then when I migrated over to setuptools I had to 
switch it to __init__.py and change around all my import statements to 
compensate.  Then I can reference it as an entry point.

This feels silly.  I'm sure I could go stumbling around until I come up 
with an elegant solution, but does anyone already have one?

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Setuptools, __init__ and __main__

[Ben Finney]

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 the Python Packaging Authority exists
https://www.pypa.io/> which has tended to steadily improve the
ecosystem in recent years.

> 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, because it's an application rather
> than a library. But then when I migrated over to setuptools I had to
> switch it to __init__.py and change around all my import statements to
> compensate. Then I can reference it as an entry point.

Yes, it's one of the enduring bad parts of Python that it makes the
command-line invocation of an application overly awkward.

What do you mean by “initialization stub”? That could mean a lot of
different things, and I don't want to guess what you mean.

As for the difference between library versus application: You should be
writing all your code as discretely-testable units anyway, and unit
tests should be importing those in order to test them. So the whole lot
needs to be in a package hierarchy of some form in order to do that.

That said, I haven't made use of the “execute a directory as a program”
Python feature, so I might be misunderstanding what the problem is.

> This feels silly. I'm sure I could go stumbling around until I come up
> with an elegant solution, but does anyone already have one?

It seems to me the problem is avoidable by ensuring from the start that
all your code is importable by your unit tests; that way, it's ready for
a Setuptools entry point declaration without changes.

-- 
 \ “Quidquid latine dictum sit, altum viditur.”  (“Whatever is |
  `\  said in Latin, sounds profound.”) —anonymous |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Setuptools, __init__ and __main__

[Dave Angel]

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 state for a long
stretch of years, but now the Python Packaging Authority exists
https://www.pypa.io/> which has tended to steadily improve the
ecosystem in recent years.


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, because it's an application rather
than a library. But then when I migrated over to setuptools I had to
switch it to __init__.py and change around all my import statements to
compensate. Then I can reference it as an entry point.


Yes, it's one of the enduring bad parts of Python that it makes the
command-line invocation of an application overly awkward.

What do you mean by “initialization stub”? That could mean a lot of
different things, and I don't want to guess what you mean.

As for the difference between library versus application: You should be
writing all your code as discretely-testable units anyway, and unit
tests should be importing those in order to test them. So the whole lot
needs to be in a package hierarchy of some form in order to do that.

That said, I haven't made use of the “execute a directory as a program”
Python feature, so I might be misunderstanding what the problem is.


This feels silly. I'm sure I could go stumbling around until I come up
with an elegant solution, but does anyone already have one?


It seems to me the problem is avoidable by ensuring from the start that
all your code is importable by your unit tests; that way, it's ready for
a Setuptools entry point declaration without changes.



To this I'd like to add the caveat that both __init__.py and __main__.py 
are reserved names, and putting arbitrary code in either one is quite risky.


I suspect you're putting library code in your application code file, and 
naming it __main__ because that way you can cheat around the recursive 
import restrictions.  Please don't do that.


Organize your code so that there are no loops in the import library 
hierarchy.  If that means your application file is only six lines, so be it.


And don't name any source code __main__.py,

Finally, the mere presence of __init__.py has a special meaning, and 
code in it should probably be limited to doing namespace munging that a 
package may require to keep its public interface simpler.



--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list

Re: Setuptools, __init__ and __main__

[Rob Gaddi]

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.python.org/> helpful.
>>
>> Also know that Python packaging was in a terrible state for a long
>> stretch of years, but now the Python Packaging Authority exists
>> https://www.pypa.io/> which has tended to steadily improve the
>> ecosystem in recent years.
>>
>>> 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, because it's an application rather
>>> than a library. But then when I migrated over to setuptools I had to
>>> switch it to __init__.py and change around all my import statements to
>>> compensate. Then I can reference it as an entry point.
>>
>> Yes, it's one of the enduring bad parts of Python that it makes the
>> command-line invocation of an application overly awkward.
>>
>> What do you mean by “initialization stub”? That could mean a lot of
>> different things, and I don't want to guess what you mean.
>>
>> As for the difference between library versus application: You should be
>> writing all your code as discretely-testable units anyway, and unit
>> tests should be importing those in order to test them. So the whole lot
>> needs to be in a package hierarchy of some form in order to do that.
>>
>> That said, I haven't made use of the “execute a directory as a program”
>> Python feature, so I might be misunderstanding what the problem is.
>>
>>> This feels silly. I'm sure I could go stumbling around until I come up
>>> with an elegant solution, but does anyone already have one?
>>
>> It seems to me the problem is avoidable by ensuring from the start that
>> all your code is importable by your unit tests; that way, it's ready
>> for a Setuptools entry point declaration without changes.
>>
>>
> To this I'd like to add the caveat that both __init__.py and __main__.py
> are reserved names, and putting arbitrary code in either one is quite
> risky.
> 

Not so much risky as just, there's a thing that it does. 

> I suspect you're putting library code in your application code file, and
> naming it __main__ because that way you can cheat around the recursive
> import restrictions.  Please don't do that.
> 
> Organize your code so that there are no loops in the import library
> hierarchy.  If that means your application file is only six lines, so be
> it.
> 
> And don't name any source code __main__.py,
> 
> Finally, the mere presence of __init__.py has a special meaning, and
> code in it should probably be limited to doing namespace munging that a
> package may require to keep its public interface simpler.

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.

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 separate file.  Under other circumstances 
when the app has become substantial, the bulk of the application code 
winds up in, e.g. mainwindow.py, and the __main__ does nothing but call 
mainwindow.main().

The advice to reduce the entry point code (be it __init__ or __main__) to 
a small stub and move the bulk of the code to another library doesn't 
change the underlying situation.  Setuptools seems to require that the 
application be a "package", i.e. a thing that has an __init__.py.  But 
the python application start mechanism seems to be steering me to using a 
__main__.

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 program to foobar.py, have an empty __init__, a stub 
__main__ that just calls foobar.main(), and an entry-point of 
foobar.foobar:main .  It just feels like a bit of a heavy solution to 
have two unnecessary files.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Setuptools, __init__ and __main__

[Ethan Furman]

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 separate file.  Under other circumstances 
> when the app has become substantial, the bulk of the application code 
> winds up in, e.g. mainwindow.py, and the __main__ does nothing but call 
> mainwindow.main().

Sounds like you would have been okay to keep your code in __main__.py and have 
an empty __init__.py.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Monte Carlo probability calculation in Python

[Paul Moore]

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 relatively little 
work (considering I started not knowing much about numpy) I managed to put 
together solutions for a couple of my friend's problems which ran in basically 
the same time as his custom C code. Very impressive!

Thanks again for the help.
Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Setuptools, __init__ and __main__

[Ben Finney]

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 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 separate file.

Sure, there's no need to make more modules if the code is small and
coherent.

But you describe it as “tightly-coupled”; that's a warning sign already.
How do you automate tests of its individual units? The code should be in
separate functions with tightly-defined scope and narrow, well-specified
interfaces.

> Under other circumstances when the app has become substantial, the
> bulk of the application code winds up in, e.g. mainwindow.py, and the
> __main__ does nothing but call mainwindow.main().

Great! So you already have an entry point for Setuptools: the entry
point is something like "fooapp.mainwindow:main".

> The advice to reduce the entry point code (be it __init__ or __main__)
> to a small stub and move the bulk of the code to another [module]
> doesn't change the underlying situation. Setuptools seems to require
> that the application be a "package", i.e. a thing that has an
> __init__.py. But the python application start mechanism seems to be
> steering me to using a __main__.

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 makes something that
should be easy (write a command directly into a file and invoke that
file as an executable program) tortuously difficult when the program
comprises several modules.

> 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__.

More importantly, the core tip there is that you can write your entry
point as "fooapp.__main__:main".

> I guess I can move the program to foobar.py, have an empty __init__, a
> stub __main__ that just calls foobar.main(), and an entry-point of
> foobar.foobar:main . It just feels like a bit of a heavy solution to
> have two unnecessary files.

Well, they're small but not unnecessary. They're explicitly telling
Python the meaning of a particular directory, rather than leaving it to
guess.

The quirks of Python's import system, and especially the implications
for trying to just get ‘./fooapp’ working, are covered in a “here's some
traps to avoid” article by Nick Coghlan
http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html>.

I really wish Python had a better solution for this, but it doesn't.
This is one of the few downsides of Python's design IMO, and we just
need to work with it.

-- 
 \  “I find the whole business of religion profoundly interesting. |
  `\ But it does mystify me that otherwise intelligent people take |
_o__)it seriously.” —Douglas Adams |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Setuptools, __init__ and __main__

[Paul Moore]

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 program to foobar.py, have an empty __init__, a stub 
> __main__ that just calls foobar.main(), and an entry-point of 
> foobar.foobar:main .  It just feels like a bit of a heavy solution to 
> have two unnecessary files.

There's no real reason you have to take your code out of __init__.py, it's fine 
there. What it sounds like to have is a chunk of code that is basically the 
command line interface to your application. Presumably, if you've set things up 
for an entry point, that code is in a main() function. So the following should 
work:

-- mypkg
   |
   -- __init__.py
   def main():
  # whatever
   -- __main__.py
   import mypkg
   mypkg.main()

Then define your entry point as calling mypkg:main

This will give you an entry point script when you install your project, and the 
__main__.py file means that "python -m mypkg" will also work.

If you want a working example, pip itself uses this structure (although it's a 
bit more complicated because pip's a bit bigger :-))

Hope this helps,
Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Setuptools, __init__ and __main__

[Ethan Furman]

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 makes something that
> should be easy (write a command directly into a file and invoke that
> file as an executable program) tortuously difficult when the program
> comprises several modules.

Can you explain that a bit more?  Surely if the writing a command into a file 
was going to be easy, then so would be
writing it to __main__.py instead?

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Monte Carlo probability calculation in Python

[Steven D'Aprano]

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 interested. With relatively
> little work (considering I started not knowing much about numpy) I managed
> to put together solutions for a couple of my friend's problems which ran
> in basically the same time as his custom C code. Very impressive!


Very nice! Care to share the code?




-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Setuptools, __init__ and __main__

[Steven D'Aprano]

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/
+-- __init__.py
+-- __main__.py
+-- spam.py
+-- eggs.py
+-- cheese.py


the __init__.py file is needed for it to be recognised as a package, and the
__main__.py file is used when running the package. (Everything else is
optional, of course, although it's hard to see why you would bother with a
package instead of a single module if you weren't breaking the code up into
multiple modules.)

In other words, when you run `import myapplication` from within Python, the
__init__.py module is imported. But when you do this from the shell:

python -m myapplication


Python will search the PYTHONPATH, find the myapplication package, and run
myapplication/__main__.py as a script.

Of course, you can also run __main__.py by hand:

python /path/to/the/myapplication/__main__.py


but having Python search the path is more convenient.


> Finally, the mere presence of __init__.py has a special meaning, and
> code in it should probably be limited to doing namespace munging that a
> package may require to keep its public interface simpler.

It's conventional to have an empty __init__.py, but not required. At the
very least __init__.py should contain enough code (perhaps `from
mypackage.spam import *`) to make `import mypackage` useful.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Setuptools, __init__ and __main__

[Dave Angel]

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 file) with this structure:


myapplication/
+-- __init__.py
+-- __main__.py
+-- spam.py
+-- eggs.py
+-- cheese.py


the __init__.py file is needed for it to be recognised as a package, and the
__main__.py file is used when running the package. (Everything else is
optional, of course, although it's hard to see why you would bother with a
package instead of a single module if you weren't breaking the code up into
multiple modules.)

In other words, when you run `import myapplication` from within Python, the
__init__.py module is imported. But when you do this from the shell:

python -m myapplication


Python will search the PYTHONPATH, find the myapplication package, and run
myapplication/__main__.py as a script.


That's the main thing I just didn't know. I've seen __main__ from the 
perspective of the

if __name__ == "__main__":
where it's just an alias for the actual script name, and I didn't 
realize the duality.


Sorry for the noise.




Of course, you can also run __main__.py by hand:

python /path/to/the/myapplication/__main__.py


but having Python search the path is more convenient.



Finally, the mere presence of __init__.py has a special meaning, and
code in it should probably be limited to doing namespace munging that a
package may require to keep its public interface simpler.


It's conventional to have an empty __init__.py, but not required. At the
very least __init__.py should contain enough code (perhaps `from
mypackage.spam import *`) to make `import mypackage` useful.






--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list

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

[Ben Finney]

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 easy (write a command directly into a file and invoke that
> > file as an executable program) tortuously difficult when the program
> > comprises several modules.
>
> Can you explain that a bit more?

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.

So the correct idiom is ‘from __future__ import absolute_import’ and
keep the application's own implementation imported via relative imports
in the same package: ‘from . import implementation_detail’.

But relative import is not possible when the top-level module is
executed by the normal ‘fooprog’ usage. The top-level file is named
‘fooprog’ and is marked executable, so that it can be run directly as
soon as it's written.

Python deliberately divorces the top-level module from its package, so
it can't access its own relative modules! The relative import fails with
an ImportError “Attempted relative import in non-package”.

https://mail.python.org/pipermail/python-list/2014-November/694385.html>

So the two correct idioms – relative import for non-public modules, and
run a file directly as a command – are explicitly thwarted by Python's
import behaviour when you try to use them together.

> Surely if the writing a command into a file was going to be easy, then
> so would be writing it to __main__.py instead?

With Bash shell, or Perl, or Ruby, or countless other languages, I put
the top-level code in the *exact same file* that I'm going to execute,
named ‘fooprog’. No additional infrastructure files unless my program
architecture indicates they'll help.

Python's refusal to allow this leads to roundabout hacks like “make a
sub-directory ‘fooprog/’, write the code into ‘__main__.py’”, or “run
the program by typing ‘python -m fooprog’”, or “write a ‘./setup.py’
configuration and dicker around with Distutils's rules and install it
before you can run your program”.

A system needing baroque hacks like this doesn't really deserve to be
characterised as a “scripting language”, IMO. Fortunately, I don't like
that term anyway (we already have the term “program” for what Python
calls scripts) so avoid characterising Python that way for other reasons
too :-)

-- 
 \“Sane people have an appropriate perspective on the relative |
  `\ importance of foodstuffs and human beings. Crazy people can't |
_o__) tell the difference.” —Paul Z. Myers, 2010-04-18 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Ethan Furman]

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, because it makes something that
>>> should be easy (write a command directly into a file and invoke that
>>> file as an executable program) tortuously difficult when the program
>>> comprises several modules.
>>
>> Can you explain that a bit more?
> 
> 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 they are not in the Python module path, how are they imported at all?

> Python deliberately divorces the top-level module from its package, so
> it can't access its own relative modules! The relative import fails with
> an ImportError “Attempted relative import in non-package”.

My understanding is that imports is for libraries [1], and libraries must be in 
sys.path.  Are you saying that after
placing your top-level file's path in sys.path, that relative imports do not 
work?

--
~Ethan~

[1] which can be a single module



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Ben Finney]

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 they are not in the Python module path, how are they imported at
> all?

Only absolute imports use the module search path. The whole point of
relative imports is to import a module within the same (or a sub-)
package, without modifying the search path.

https://www.python.org/dev/peps/pep-0328/>

> > Python deliberately divorces the top-level module from its package,
> > so it can't access its own relative modules!
>
> My understanding is that imports is for libraries [1], and libraries
> must be in sys.path.

That's the arbitrary limitation I'm pointing out, yes. The program's
private implementation modules should not need to be in the global
module search path, merely to allow the top-level program to import
them.

It's contradictory to present relative imports with the justification
they are for intra-package imports, and then cripple a top-level module
so it can't access its own implementation modules via relative imports.

-- 
 \ “Capitalism is the astounding belief that the most wickedest of |
  `\men will do the most wickedest of things for the greatest good |
_o__)   of everyone.” —John Maynard Keynes |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Matplotlib import error

[Ned Deily]

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 matplotlib
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/Library/Python/2.7/site-packages/matplotlib/__init__.py",
> line 180, in 
> from matplotlib.cbook import is_string_like
>   File "/Library/Python/2.7/site-packages/matplotlib/cbook.py", line
> 33, in 

It looks like you have a mixture of packages, some left over from using 
the system Python 2.7 and, unfortunately, the system Python site-package 
directory is included at the sys.path search path for other Pythons, 
like the python.org Pythons.  If you plan to just use the Python 2.7.9, 
go to /Library/Python/2.7/site-packages and rm everything there.  Then 
use the 2.7.9 pip to install matplotlib.  It should download and install 
(to 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages) the binary wheels for matplotlib and its dependencies, including 
numpy, and all just work.

-- 
 Ned Deily,
 n...@acm.org

-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Rustom Mody]

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
> > > site package, they normally only need to be local to the
> > > application.
> >
> > If they are not in the Python module path, how are they imported at
> > all?
> 
> Only absolute imports use the module search path. The whole point of
> relative imports is to import a module within the same (or a sub-)
> package, without modifying the search path.
> 
> https://www.python.org/dev/peps/pep-0328/>
> 
> > > Python deliberately divorces the top-level module from its package,
> > > so it can't access its own relative modules!
> >
> > My understanding is that imports is for libraries [1], and libraries
> > must be in sys.path.
> 
> That's the arbitrary limitation I'm pointing out, yes. The program's
> private implementation modules should not need to be in the global
> module search path, merely to allow the top-level program to import
> them.
> 
> It's contradictory to present relative imports with the justification
> they are for intra-package imports, and then cripple a top-level module
> so it can't access its own implementation modules via relative imports.

Thanks Ben for these points.

We techies need to always slide the rheostat along:

1. I am dumb
2. I am ignorant - need to read up some
3. Stuff is complex - more to read up
4. Stuff is complicated - after all the reading up, some general ideas may 
get clear but there remain all sorts of dark nooks and crannies
5. Stuff is a complete bloody mess - anyone who claims to understand, doesn't 
understand and doesn't understand that he doesn't understand.
[Think Stroustrup saying something to the effect it takes a lifetime to learn 
C++ !]

Your points and the earlier thread have helped me to slide the rheostat a 
couple of notches down!

My analysis of the problem:

Python docs are a model of clarity... mostly.
They fail when the rubber hits the road - OS-specific stuff.

In the attempt at keeping the docs generic, when things like how the 'insides'
of python map to the 'outsides' - file-system-mapping - I find the docs are 
sorely inadequate. [You are of course free to slide my rheostat up :-) ]

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 as
https://www.debian.org/doc/packaging-manuals/python-policy/

And the dark unexplored territory in between.
[Its a research project to figure out clashes between pip and apt]

Hopefully python-devs will give up trying to be generic in this area and start
documenting these things in an OS-specific way.

Yeah I know it can be significantly more of a babel than just:
Windows - This-a-way
Linux - That-a-way

eg:
- Mismatch between say Fedora and Debian
- Different 32-64 bit path-disambiguation on different windows systems
- etc

Still... we need to bite the bullet

Since this has been somewhat of a rant I should say:
Wherever comparable to python we may look, its just like this or worse.

Perl/Ruby are probably slightly more mature
Haskell is much worse - search for "cabal hell" 
Latex is probably about the same: eg a debian texlive bugreport of mine:
https://lists.debian.org/debian-tex-maint/2014/06/msg00029.html
followed by unhelpful/improper response of the debian-dev
-- 
https://mail.python.org/mailman/listinfo/python-list

help for using Python rsa

[mhr1224]

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:
message = 'hello Bob!'
crypto = rsa.encrypt(message, pubkey)

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 like this:
SEcPB1mYNrfeE4zP4RI3z2K4Rh9HDNfPhuF28IyxHFjEOJ9Z+1zdIwPF0jsJGQDJyKpAju7dcYueHHXXeH8d+w==

How can i change the format of this?

-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Rustom Mody]

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 as
> https://www.debian.org/doc/packaging-manuals/python-policy/
> 
> And the dark unexplored territory in between.
> [Its a research project to figure out clashes between pip and apt]
> 

Small example of this which I just tried.
Wanted to try out sympy.
apt-install promised ¼ GB download, ¾ GB space usage

Just getting a src-tarball was: 6M download, 30M after opening the tar.

Sure the full stuff with tex fonts and all may be pretty.
But does not seem necessary to push it down everyone's throat unless 
needed/desired
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: help for using Python rsa

[Dave Angel]

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='PEM')

When i encrypt massage with this keys:
 message = 'hello Bob!'
 crypto = rsa.encrypt(message, pubkey)

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 like this:
SEcPB1mYNrfeE4zP4RI3z2K4Rh9HDNfPhuF28IyxHFjEOJ9Z+1zdIwPF0jsJGQDJyKpAju7dcYueHHXXeH8d+w==

How can i change the format of this?



I can't help with the crypto, but I can help make it more likely that 
someone will be able to help.


1) Always specify the Python version and OS when you start a new thread.

2) When you show data, show how you're displaying that data.  You have 
two strings, but the one is apparently a repr() of a string, while the 
other is not.  And you don't specify how you "know it should be like 
this."  Are you running some other encryption utility that gives you 
that message?  Be specific.  Something like:


crypto = rsa.enc
print( repr(crypto) )

displays as
"@\xc4\xb2\x...

but runningmycrypto.exe  key="xyzyzzyzyzy"  data="hello Bob!"
displays as
SEcPB1mYNrf...

Have you tried decrypting the encrypted message, using the privkey?  Did 
it in fact produce the original?  Could it be that the error is in how 
you're transporting the public key to your reference program?


It might also be useful to show the types of each of the variables.  For 
example, you probably cannot encrypt text, but only binary.  So you 
might need to explicitly encode the text "hello Bob!" before encrypting it.


--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list

Re: help for using Python rsa

[Chris Angelico]

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 like this:
> SEcPB1mYNrfeE4zP4RI3z2K4Rh9HDNfPhuF28IyxHFjEOJ9Z+1zdIwPF0jsJGQDJyKpAju7dcYueHHXXeH8d+w==
>
> How can i change the format of this?

That looks like Base 64 encoded text, which you can easily produce
from Python. But that isn't the base-64 encoded version of the above
binary blob.

Are you asking how to base-64 something, or are you specifically
expecting that output?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list