Re: Couldn't load SIP module.
On 11/19/2016 01:44 PM, Xristos Xristoou wrote:
> hello
> i using python 2.7.12 on ubuntu 16.04 and i have that error with SIP :
>
> Couldn't load SIP module.
>
>
> Traceback (most recent call last):
> File "", line 1, in
> ImportError: /usr/local/lib/python2.7/site-packages/sip.so: undefined symbol:
> PyUnicodeUCS2_AsUTF8String
>
> ('Qt version:', '4.8.7')
> ('SIP version:', '4.17')
> ('PyQt version:', '4.11.4')
>
> any idea how to fix that ?
Looks like you're playing with a custom-compiled version of Python, as
/usr/local/python2.7 is not a normal Ubuntu path for Python to be
installed as far as I know. Feel free to correct me. I suspect there's
some impedance mismatch between your custom version of Python and the
system-supplied libraries that sip.so may be depending on.
I'm pretty sure Ubuntu 16.04 ships with a pretty current version of
Python 2.7 and also Python 3. It will probably be way easier to work
with the Ubuntu-provided Python versions than to compile you're own,
unless you have a good reason to do so. Try deleting your custom
installation of Python and use the Ubuntu software manager or apt-get to
install PyQt and the sip dependencies.
--
https://mail.python.org/mailman/listinfo/python-list
Re: help on "from deen import *" vs. "import deen"
On 11/19/2016 08:46 AM, Steve D'Aprano wrote: > I think you're being harsh on J Fong. And for what it is worth, I think that > I (slightly) agree with him: in my experience, many people have difficulty > understanding object model at first, especially if they've come from a > background of named memory boxes. > > You should spend more time around beginners -- it is quite common for them > to be confused by name binding and all its consequences. I don't know if it > is "most novices", but I'm confident that it is quite common. Yes, I can see that you're correct. I apologize to Mr Fong for my impatience. Python is pretty cool, and I hope it starts to click for you. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to append a modified list into a list?
Peter Otten at 2016/11/19 5:40:34PM wrote: > And now for something completely different ;) > > What if you only record the changes to the list? For a long list that would > save space at the expense of calculation time. For example: Excellent! Although not 100% fit into my application, I must study how this Class works. Thank you. --Jach -- https://mail.python.org/mailman/listinfo/python-list
Re: Extra base class in hierarchy
Ian Kelly wrote: Is it better to introduce an extra base class? That's one possibility. An advantage would be that it would be easier to add methods in the future that apply to UsualTreeNodes but not FinalTreeNodes. Another possibility would be to just rename the classes. Instead of FinalTreeNode and UsualTreeNode, call them something like TreeNode and NonFinalTreeNode, with NonFinalTreeNode inheriting from TreeNode. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Couldn't load SIP module.
hello
i using python 2.7.12 on ubuntu 16.04 and i have that error with SIP :
Couldn't load SIP module.
Traceback (most recent call last):
File "", line 1, in
ImportError: /usr/local/lib/python2.7/site-packages/sip.so: undefined symbol:
PyUnicodeUCS2_AsUTF8String
('Qt version:', '4.8.7')
('SIP version:', '4.17')
('PyQt version:', '4.11.4')
any idea how to fix that ?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Extra base class in hierarchy
On Nov 19, 2016 11:22 AM, "Victor Porton" wrote: Consider class FinalTreeNode(object): def childs(self): return [] class UsualTreeNode(FinalTreeNode) def childs(self): return ... In this structure UsualTreeNode derives from FinalTreeNode. This looks odd because "final" in OOP usually denotes something that will not be further inherited. Is it better to introduce an extra base class? Without knowing what UsualTreeNode and FinalTreeNode are it's hard to say. class BaseTreeNode(object): def childs(self): return [] # The same functionality as BaseTreeNode, but logically distinct class FinalTreeNode(BaseTreeNode): pass That's a bit of a code smell. Why do you need a subclass if the implementation is the same? Probably you should implement the common parts in the base class and differentiate both of the subclasses. Also a pet peeve of mine is the word "base" in class names. Just call it TreeNode. -- https://mail.python.org/mailman/listinfo/python-list
Extra base class in hierarchy
Consider class FinalTreeNode(object): def childs(self): return [] class UsualTreeNode(FinalTreeNode) def childs(self): return ... In this structure UsualTreeNode derives from FinalTreeNode. Is it better to introduce an extra base class? class BaseTreeNode(object): def childs(self): return [] # The same functionality as BaseTreeNode, but logically distinct class FinalTreeNode(BaseTreeNode): pass # Not derived from FinalTreeNode, because it is not logically final class UsualTreeNode(BaseTreeNode) def childs(self): return ... -- Victor Porton - http://portonvictor.org -- https://mail.python.org/mailman/listinfo/python-list
Re: Two variants of class hierachy
Peter Otten wrote: > Victor Porton wrote: > >> I am developing software which shows hierarchical information (tree), >> including issues and comments from BitBucket (comments are sub-nodes of >> issues, thus it forms a tree). >> >> There are two kinds of objects in the hierarchy: a. with a (possibly >> long) paginated list of childs; b. with a short list of strings, each >> string being associated with a child object. >> >> I have two variants of class inheritance in mind. Please help to decide >> which is better. >> >> The first one declares only one base class, but some its method remain >> unimplemented (raise NotImplementedError) even in derived classes. > > Two observations: > > In Python you can also use "duck-typing" -- if you don't want to share > code between the classes there is no need for an inhertitance tree at all. I know, but explicit inheritance serves as a kind of documentation for readers of my code. > Pagination is a matter of display and will be handled differently in a PDF > document or web page, say. I would not make it part of the data structure. Not in my case, because the data I receive is already paginated. I am not going to "re-paginate" it in another way. -- Victor Porton - http://portonvictor.org -- https://mail.python.org/mailman/listinfo/python-list
Re: Two variants of class hierachy
Victor Porton wrote: > I am developing software which shows hierarchical information (tree), > including issues and comments from BitBucket (comments are sub-nodes of > issues, thus it forms a tree). > > There are two kinds of objects in the hierarchy: a. with a (possibly long) > paginated list of childs; b. with a short list of strings, each string > being associated with a child object. > > I have two variants of class inheritance in mind. Please help to decide > which is better. > > The first one declares only one base class, but some its method remain > unimplemented (raise NotImplementedError) even in derived classes. Two observations: In Python you can also use "duck-typing" -- if you don't want to share code between the classes there is no need for an inhertitance tree at all. Pagination is a matter of display and will be handled differently in a PDF document or web page, say. I would not make it part of the data structure. -- https://mail.python.org/mailman/listinfo/python-list
Re: C3 MRO
On Sun, Nov 20, 2016 at 3:21 AM, Victor Porton wrote: > Do I understand correctly, than C3 applies to particular methods, and thus > it does not fail, if it works for every defined method, even if it can fail > after addition of a new method? > > Also, at which point it fails: at definition of a class or at calling a > particular "wrong" method? It either succeeds or fails for the entire class. If it fails, you get an exception at class definition time: class A: pass class B: pass class C(A, B): pass class D(B, A): pass class E(C, D): pass Traceback (most recent call last): File "", line 1, in TypeError: Cannot create a consistent method resolution order (MRO) for bases A, B ChrisA -- https://mail.python.org/mailman/listinfo/python-list
C3 MRO
Do I understand correctly, than C3 applies to particular methods, and thus it does not fail, if it works for every defined method, even if it can fail after addition of a new method? Also, at which point it fails: at definition of a class or at calling a particular "wrong" method? -- Victor Porton - http://portonvictor.org -- https://mail.python.org/mailman/listinfo/python-list
Re: help on "from deen import *" vs. "import deen"
On Fri, 18 Nov 2016 03:14 pm, Michael Torrie wrote: > On 11/17/2016 08:41 PM, jf...@ms4.hinet.net wrote: >> The fact that most novices will stumble on Python variable many times >> until it becomes his "second nature" proves it's different from the >> human language:-) > > The fact is that most novices don't stumble when dealing with Python > variables. The nature of name binding vs memory boxes does trip up > people occasionally, but most grasp it quickly and move on. > > Since you are unwilling to prove your assertion or even provide a single > example (you did once speak of couches and chairs but your reference > made little sense), we can make no further progress. I think you're being harsh on J Fong. And for what it is worth, I think that I (slightly) agree with him: in my experience, many people have difficulty understanding object model at first, especially if they've come from a background of named memory boxes. You should spend more time around beginners -- it is quite common for them to be confused by name binding and all its consequences. I don't know if it is "most novices", but I'm confident that it is quite common. Coincidentally, on the Python tutor list, there was an example of this earlier yesterday: https://mail.python.org/pipermail/tutor/2016-November/110014.html This is not just Python, of course, it includes most modern scripting languages and some non-scripting languages. E.g. Lua, Javascript, Ruby and Java (objects and boxed values, but not machine values). It's not that Python is doing something weird compared to other languages. Python's name binding semantics are very common. They also have a lot in common with pointer semantics in C-like and Algol-like languages: you have to reason through a level of indirection to understand variables. And pointer semantics are notoriously difficult. So I don't think it should be surprising that some people find it hard to understand, at least at the beginning. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Two variants of class hierachy
I am developing software which shows hierarchical information (tree), including issues and comments from BitBucket (comments are sub-nodes of issues, thus it forms a tree). There are two kinds of objects in the hierarchy: a. with a (possibly long) paginated list of childs; b. with a short list of strings, each string being associated with a child object. I have two variants of class inheritance in mind. Please help to decide which is better. The first one declares only one base class, but some its method remain unimplemented (raise NotImplementedError) even in derived classes. The second one defines two distinct base classes HierarchyLevelWithPagination (for objects of above described class "a") and HierarchyLevelWithShortList (for objects of above described class "b"), but use multiple inheritance. # VARIANT 1: # class HierarchyLevel(object): def get_node(self): return None def childs(self, url, page, per_page=None): raise NotImplementedError() def short_childs(self): raise NotImplementedError() class BitBucketHierarchyLevel(HierarchyLevel): ... # A implements only childs() but not short_childs() class A(BitBucketHierarchyLevel): ... # B implements only short_childs() but not childs() class B(BitBucketHierarchyLevel): ... ## OR ## # VARIANT 2: # class HierarchyLevel(object): def get_node(self): return None class HierarchyLevelWithPagination(HierarchyLevel): def childs(self, url, page, per_page=None): raise NotImplementedError() class HierarchyLevelWithShortList(HierarchyLevel): def short_childs(self): raise NotImplementedError() ## THEN ## # code specific for BitBucket class BitBucketHierarchyLevel(HierarchyLevel): ... # diamonds: class A(BitBucketHierarchyLevel, HierarchyLevelWithPagination): ... class B(BitBucketHierarchyLevel, HierarchyLevelWithShortList): ... -- Victor Porton - http://portonvictor.org -- https://mail.python.org/mailman/listinfo/python-list
Re: help on "from deen import *" vs. "import deen"
Chris Angelico at 2016/11/19 2:58:41PM wrote: > On Sat, Nov 19, 2016 at 3:34 PM, Steve D'Aprano > wrote: > > What happens if you do this? > > > > spam = eggs = cheese = obj > > > > Is that different from: > > > > spam = obj > > eggs = obj > > cheese = obj > > > > > > or from this? > > > > spam = obj > > eggs = spam > > cheese = eggs > > ... > > These aren't silly questions. > > Indeed, they are not silly. It surprised me (as a C programmer) that > the assignments happen left-to-right, rather than right-to-left (in C, > cheese would be set first, then eggs, then spam). These are questions > filled with subtleties. > > ChrisA Why this conversation makes me feel like a fool? Are they different? --Jach -- https://mail.python.org/mailman/listinfo/python-list
Re: How to append a modified list into a list?
jf...@ms4.hinet.net wrote:
> I have a working list 'tbl' and recording list 'm'. I want to append 'tbl'
> into 'm' each time when the 'tbl' was modified. I will record the change
> by append it through the function 'apl'.
>
> For example:
>
tbl=[0,0]
m=[]
>
tbl[0]=1
apl(tbl)
m
> [[1,0]]
>
tbl[1]=2
apl(tbl)
m
> [[1,0], [1,2]]
>
> How to define this function properly?
>
> Obviously the most intuitive way doesn't work.
> def apl0(tbl):
> m.append(tbl)
>
> and introducing a local variable will not help either.
> def apl1(tbl):
> w=tbl
> m.append(w)
>
> I figure out a workable way, but looks ugly.
> def apl2(tbl):
> w=[]
> w[:]=tbl
> m.append(w)
>
> I know those binding tricks between names and objects. Just wondering if
> there is an elegant way of doing this:-)
>
> --Jach
And now for something completely different ;)
What if you only record the changes to the list? For a long list that would
save space at the expense of calculation time. For example:
$ cat list_history.py
import collections
from itertools import islice
class List(collections.Sequence):
def __init__(self, items):
self._items = list(items)
self._history = []
def __setitem__(self, index, value):
if isinstance(index, slice):
value = list(value)
old = self._items[index]
if len(old) != len(value):
raise ValueError("size changes not supported")
else:
old = self._items[index]
self._history.append((index, old))
self._items[index] = value
def __getitem__(self, index):
return self._items[index]
def __len__(self):
return len(self._items)
def __repr__(self):
return repr(self._items)
def historic_state(self, n):
items = self._items[:]
for index, value in islice(reversed(self._history), n):
items[index] = value
return items
def history_len(self):
return len(self._history) + 1
if __name__ == "__main__":
items = List("abcdefghijk")
print(items)
# apply some changes
items[3] = "foo"
items[7] = "bar"
items[3] = 42
items[3:6] = "xyz"
items[5:7] = (1, 2)
print(items)
# let's go back in time
for i in range(items.history_len()):
print("#{}: {}".format(i, items.historic_state(i)))
$ python3 list_history.py
['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k']
['a', 'b', 'c', 'x', 'y', 1, 2, 'bar', 'i', 'j', 'k']
#0: ['a', 'b', 'c', 'x', 'y', 1, 2, 'bar', 'i', 'j', 'k']
#1: ['a', 'b', 'c', 'x', 'y', 'z', 'g', 'bar', 'i', 'j', 'k']
#2: ['a', 'b', 'c', 42, 'e', 'f', 'g', 'bar', 'i', 'j', 'k']
#3: ['a', 'b', 'c', 'foo', 'e', 'f', 'g', 'bar', 'i', 'j', 'k']
#4: ['a', 'b', 'c', 'foo', 'e', 'f', 'g', 'h', 'i', 'j', 'k']
#5: ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k']
--
https://mail.python.org/mailman/listinfo/python-list
