Re: Design an encrypted time-limited API on Client/Server side
iMath writes:
> ?I am planning design an encrypted time-limited API on both Client and Server
> sides, the server side is written in Django, the client side is a GUI program
> which call the API by
> import requests
> c = requests.post("http://127.0.0.1:8000/VideoParser/";, data={'videoUrl':
> videoUrl })
> The way it call the API is desperately exposed to those who can use network
> traffic capturing tools like wireshark and fiddler
You could require the "https" protocol to prevent this.
> while I don't want anyone else could call the API with their customized
> videoUrl, and if people made the post call with the same parameters 2 minutes
> later after the client initially made the call, the call should be valid or
> expired, so how to design the encrypted time-limited API on both Client and
> Server side in this case ?
There is a general concept of "one-time-url" to handle cases such
as this one. These are urls which can be used just once.
Usually, they have associated an expiration date
and an uuid. The uuid is used on the server to maintain state (still
unused, already used); the expiration date allows state cleanup.
--
https://mail.python.org/mailman/listinfo/python-list
what is wrong with this property setter
class Test: def __init__(self): self._parent = None @property def parent(self): return self._parent @parent.setter def set_parent(self, new_parent): self._parent = new_parent p, c = Test(), Test() c.parent = p >py -3 test.py Traceback (most recent call last): File "test.py", line 15, in c.parent = p AttributeError: can't set attribute BTW this does work, but it is not that elegant: class Test: def __init__(self): self._parent = None def get_parent(self): return self._parent def set_parent(self, new_parent): self._parent = new_parent parent = property(get_parent, set_parent) p, c = Test(), Test() c.parent = p -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Op 08-06-16 om 18:37 schreef Marko Rauhamaa: > Antoon Pardon : > >> You can do something like that in simula, but only because >> simula has two kinds of assignments. One kind that is >> simular to python and one that is similar to C. >> The one that is similar that python is the reference assignment. > I see Python as doing the exact same thing with variables as C. > > What is different is that in Python, every expression evaluates to a > pointer. Thus, you can only assign pointers to variables. Then you think wrong. Python has no pointers, that is an implementation detail. In python when you have two variables, and you assign one to the other you then have two variables that share an object. In C when you have two variables and you assign one to the other you then have two variable each refering to their own object that are copies of each other. And yes that sharing of variables in python can be simulated by copying pointers in C. Maybe the simularities between variables in python can be made isomorphic with a specific subset of pointer operations in C. The fact is that such an isomorphism would be limited to specific pointer operations and would not extend to how variable generally behave in C. In a rather straight forward environment with classes/structs that have an x and y attribute, the following lines behave differently in C and Python. A.x = 1; A.y = 2; B = A; B.x = 3; B.y = 4; In C the variable A will still be x:1, y:2. In Python the variable A will be x:3, y:4. So no, Python doesn't do the exact same thing with variables as C. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
On Wednesday 08 June 2016 19:41, Antoon Pardon wrote: >> What you seem to be describing is similar to reference parameter semantics >> from Pascal. Assignment doesn't work that way in C, or Python. > > I disagree. In python the assignment does work similar to the reference > parameter semantics in pascal. See the following > > A = range[4] > B = A > B[2] = 5 > print A # [0, 1, 5, 2] > > This is exactly the result you would get with B as a reference parameter in > pascal. It might be the same result, but it is a different cause. Your example demonstrates object mutation, not assignment. Although Python uses the same syntax X = X for both name binding (assignment) and item assignment, item assignment is a *mutator method*: it calls B.__setitem__, which modifies B in place. Since the name A is bound to the same object, it is hardly surprising that A shows the same change. But since you think that assignment in Python behaves like Pascal var parameters (reference variables), you should be able to write a "swap" procedure that swaps two arguments. That's the definitive test for reference parameters, since it works in all languages with reference parameters (e.g. Pascal, Basic and C++), and doesn't work in any language without them (or equivalent, like Algol's pass-by-name parameters). The Pythonic way to swap two variables is to use tuple unpacking: a, b = b, a but that uses a completely different mechanism to get the same effect. "Reference parameter" is all about mechanism. I want to see the Python equivalent of Pascal's var parameters: procedure swap(var a:integer; var b:integer); var temp: integer; begin temp := a; a := b; b := a; end; (or the Algol equivalent, a slightly different mechanism), and then see it called like this: a = 1 b = 2 swap(a, b) # absolutely NOT `a, b = swap(a, b)` assert a == 2 and b == 1 without passing in or making use of hard-coded parameter names. That is my challenge to you: if you can write such a function, in pure Python, which swaps two parameters given as ordinary arguments (passing their names as strings does not count), then I will cheerfully apologise for doubting you, admit that I was wrong, and publicly acknowledge that Python does have reference variables just like you said. If you cannot meet that challenge, then I would like you to acknowledge that whatever Python variables are, and however Python's assignment works, it is *not* the same as Pascal's reference variables, and so calling Python variables "reference variables" is misleading and an abuse of a well-established term from computer science since long before Python even existed. Are you willing to accept that challenge? Or are you going to try to weasel out of it by changing the definition of reference parameter to mean "whatever I want it to mean to avoid admitting I was wrong"? >> And of course Python doesn't have reference variables either. There is >> nothing you can do in Python to get this effect: >> >> a = 1 >> b = a >> b = 99 >> assert a == 99 > > It is true that you can't get such an effect in python, but that doesn't > imply that python doesn't have reference variables (as an abstract notion). > Because having reference variables doesn't imply you can have that effect. Ah, well that answers that question. Weasel out it is. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with this property setter
On Thursday, June 9, 2016 at 8:28:47 AM UTC+1, Nagy László Zsolt wrote: > class Test: > def __init__(self): > self._parent = None > > @property > def parent(self): > return self._parent > > @parent.setter > def set_parent(self, new_parent): > self._parent = new_parent > > > p, c = Test(), Test() > c.parent = p > > >py -3 test.py > > Traceback (most recent call last): > File "test.py", line 15, in > c.parent = p > AttributeError: can't set attribute > > BTW this does work, but it is not that elegant: > > class Test: > def __init__(self): > self._parent = None > > def get_parent(self): > return self._parent > > def set_parent(self, new_parent): > self._parent = new_parent > > parent = property(get_parent, set_parent) > > > p, c = Test(), Test() > c.parent = p Change the name of the setter from set_parent to parent, i.e., @parent.setter def parent(self, new_parent): ... That works for me on Python 3.4. -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Op 08-06-16 om 19:29 schreef BartC: > I don't see why we should determine what a /proper/ reference >> can do, based on what it does in one specific language. > > Because there are some things that such references can do that Python > can't do with its object reference model, not without some difficulty > or having to write convoluted code. So? Maybe you have the wrong idea of what a reference is/can do? A reference is an alias. What you can do with that depends of the work environment. That you can do different things in an evironment that has a copy assignment than in an environment where you don't doesn't make the aliases go away. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with this property setter
On Thursday 09 June 2016 17:28, Nagy László Zsolt wrote: > class Test: Are you using Python 3 or 2? In Python 2, property doesn't work correctly with classes unless they inherit from object (directly or indirectly). > def __init__(self): > self._parent = None > > @property > def parent(self): > return self._parent > > @parent.setter > def set_parent(self, new_parent): > self._parent = new_parent If you use the "setter" method, you must use the same name, in this case "parent", for each part of the property. If you want to give your getters and setters different names, you have to use the older property API: class Test(object): def get_parent(self): ... def set_parent(self, value): ... parent = property(get_parent, set_parent) The reason why your code doesn't work is because of the way decorator syntax is defined. You have: @property def parent(self): ... which becomes: parent = property(parent) Then you have: @parent.setter def set_parent(self, new_parent): which becomes: set_parent = parent.setter(set_parent) which leaves you with TWO property objects, not one: (1) parent has a getter but no setter; (2) set_parent has a getter and setter (I think). -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with this property setter
Nagy László Zsolt wrote:
> class Test:
> def __init__(self):
> self._parent = None
>
> @property
> def parent(self):
> return self._parent
>
> @parent.setter
> def set_parent(self, new_parent):
> self._parent = new_parent
>
>
> p, c = Test(), Test()
> c.parent = p
>
>>py -3 test.py
>
> Traceback (most recent call last):
> File "test.py", line 15, in
> c.parent = p
> AttributeError: can't set attribute
Does this interactive session help you solve it yourself?
$ python3 -i test.py
Traceback (most recent call last):
File "test.py", line 15, in
c.parent = p
AttributeError: can't set attribute
>>> [n for n in dir(p) if not n.startswith("_")]
['parent', 'set_parent']
>>> p.set_parent = 42
>>> p.parent
42
Spoiler below if you don't see the light.
> @parent.setter
> def set_parent(self, new_parent):
> self._parent = new_parent
This creates a settable property with the name "set_parent" and leaves the
read-only property "parent" alone. To fix your class change the above to
@parent.setter
def parent(self, new_parent):
self._parent = new_parent
--
https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On Thursday 09 June 2016 10:34, Lawrence D’Oliveiro wrote: > In my undergraduate Comp Sci classes, we used to discuss arbitrary rules like > limiting functions to n lines. With real-world experience, it soon became > clear that such rules were a waste of time. A function should be just as big > as it needs to be, no more, no less. The same with a class, or a module. Or > whatever other constructs your language may have. The opposite of "arbitrary limits" is not "no limits". An arbitrary limit like "500 lines is the maximum size a function may be" is clearly arbitrary and not very helpful. (Also too high.) Better is to understand that there is no hard cut-off between "acceptable" and "too long", but we can still judge that all else being equal, long functions are worse than short functions. The real problem is complexity of functions. The more complex they are, the harder they are to write correctly, and the harder to maintain, and the more likely that they have bugs. The length of a function is a very crude measure of complexity, but it *is* a measure of complexity, and people are right to look at long functions as a code smell and a sign that the function probably does too much, or is badly written, or that it could do with some refactoring to simplify it. Not in *every* case, but I've never yet seen a long (> 200 lines) function that wasn't improved by refactoring or splitting. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with this property setter
>> @parent.setter >> def set_parent(self, new_parent): >> self._parent = new_parent > This creates a settable property with the name "set_parent" and leaves the > read-only property "parent" alone. Yes, and more. That property will also have a get method! Is it intentional? -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with this property setter
Nagy László Zsolt wrote: > >>> @parent.setter >>> def set_parent(self, new_parent): >>> self._parent = new_parent >> This creates a settable property with the name "set_parent" and leaves >> the read-only property "parent" alone. > Yes, and more. That property will also have a get method! Is it > intentional? It's a logical effect of how the setter() method works. The above is syntactic sugar for def set_parent(...): ... set_parent = parent.setter(set_parent) and parent.setter() creates a new property basically like this def setter(self, fset): return property(self.fget, fset, ...) Not very elegant, but I don't see a cleaner alternative. -- https://mail.python.org/mailman/listinfo/python-list
UserList - which methods needs to be overriden?
Hi, I would like to create a collections.UserList subclass that can notify others when the list is mutated. I'm not sure which methods I need to override. I have checked the sources, and it seems difficult to figure out which methods needs to be overriden. For example, MutableSequence.extend is just a for loop that calls append(). Also, the clear() method just calls pop() until the sequence becomes empty. But UserList overrides extend, so if I ever want to know when the list is modified, I need to override extend() too. There are lots of base classes (UserList, MutableSequence, Sequence ) etc and some mutating methods might be inherited from those. I'll also have to do this for UserDict (which is a MutableMapping, which is a Mapping). Is there a way to easily find out which methods of are mutating the collection? Other than going over the source and checking all (normal and inherited) methods? And finally: set is a built in container type, but we don't have a UserSet in collections. Was it ever proposed to be added to collections? Thanks, Laszlo -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
On 09/06/2016 08:50, Antoon Pardon wrote: Op 08-06-16 om 19:29 schreef BartC: I don't see why we should determine what a /proper/ reference can do, based on what it does in one specific language. Because there are some things that such references can do that Python can't do with its object reference model, not without some difficulty or having to write convoluted code. So? Maybe you have the wrong idea of what a reference is/can do? Maybe. Maybe in all the languages I've been implementing for three decades have implemented references and pointers wrongly. A reference is an alias. Not really. My address is not an alias for my house (the latter is a 2-storey brick building, the former is a few lines on an envelope). A reference and what it refers to are a little different. (What /I/ call an alias is demonstrated by a language feature I used to implement like this: int a int b @ a a := 18 println b # 18 b := 21 println a # 21 Here, b is a synonym for a; another name for the same variable.) What you can do with that depends of the work environment. That you can do different things in an evironment that has a copy assignment than in an environment where you don't doesn't make the aliases go away. Well, all my implementations of references and pointers meet Steven D'Apranso' swap() challenge (see his post in this thread about 90 minutes before this one). And in fact, my new languages have a built-in swap operator that internally depends on the kinds of references that Python doesn't have. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with this property setter
>> Yes, and more. That property will also have a get method! Is it >> intentional? > It's a logical effect of how the setter() method works. The above is > syntactic sugar for > > def set_parent(...): >... > set_parent = parent.setter(set_parent) > > and parent.setter() creates a new property basically like this > > def setter(self, fset): > return property(self.fget, fset, ...) This I could not find, because property is a built-in. But I believe you. :-) > > Not very elegant, but I don't see a cleaner alternative. It can be used to define an alternative setter for the same property, but it is bad practice. Thank you for the clarification. -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Antoon Pardon :
> Op 08-06-16 om 18:37 schreef Marko Rauhamaa:
>> I see Python as doing the exact same thing with variables as C.
>>
>> What is different is that in Python, every expression evaluates to a
>> pointer. Thus, you can only assign pointers to variables.
>
> Then you think wrong. Python has no pointers, that is an
> implementation detail.
Call it what you want, but the semantics of Python is only
understandable through references (pointers, handles, leashes,
addresses) to objects. Furthermore, there is no expression in Python
that would evaluate to a reference to a variable. While variables may
(or may not) be objects, they definitely are *not* first-class objects
because of this important limitation.
> In python when you have two variables, and you assign one to the other
> you then have two variables that share an object.
When you say A and B "share" an object, I say A and B contain a pointer
(= reference) to the same object. It's simply a question of terminology,
although I haven't seen "sharing" used in this context. A "reference"
would be a great word (as in "reference counting"), but you recently
have wanted to use that word for variables.
> In C when you have two variables and you assign one to the other you
> then have two variable each refering to their own object that are
> copies of each other.
Maybe you didn't quite understand what I have written above. In C,
expressions can evaluate to values of these types (simplified):
int
long
double
pointer
struct
void (debatable)
However, note that C does *not* have any expression that would evaluate
to an object of these types:
char
short
float
array
function
Now, Python all expressions yield references:
[] evaluates to a reference (= pointer) to a fresh empty array
1 + 2 evaluates to a reference (= pointer) to an integer
1 / 2 evaluates to a reference (= pointer) to a float
".".join evaluates to a reference (= pointer) to a function
Both languages provide the syntax:
lvalue = expression
In light of the languages' respective expression semantics, the
semantics of the assignment statements coincide. Both languages evaluate
the expression ("rvalue") and place the result in the left-hand slot
("lvalue").
> And yes that sharing of variables in python can be simulated by
> copying pointers in C.
A "pointer" is an abstract concept both in C and Python. C does have a
much richer pointer semantics than Python. For example, C provides
pointer arithmetics.
> Maybe the simularities between variables in python can be made
> isomorphic with a specific subset of pointer operations in C.
Now we are talking. "Isomorphic" is the only useful meaning of sameness.
> In a rather straight forward environment with classes/structs that
> have an x and y attribute, the following lines behave differently
> in C and Python.
>
> A.x = 1;
> A.y = 2;
>
> B = A;
>
> B.x = 3;
> B.y = 4;
>
> In C the variable A will still be x:1, y:2.
> In Python the variable A will be x:3, y:4.
>
> So no, Python doesn't do the exact same thing with variables as C.
The difference is not in the variables but in the expressions. In
Python,
1
evaluates to a pointer; in C, it evaluates to an int. Furthermore, in
Python,
A
evaluates to a pointer; in C, it evaluates to a struct.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: UserList - which methods needs to be overriden?
Nagy László Zsolt wrote: > I would like to create a collections.UserList subclass that can notify > others when the list is mutated. I'm not sure which methods I need to > override. I have checked the sources, and it seems difficult to figure > out which methods needs to be overriden. For example, > MutableSequence.extend is just a for loop that calls append(). Also, the > clear() method just calls pop() until the sequence becomes empty. But > UserList overrides extend, so if I ever want to know when the list is > modified, I need to override extend() too. There are lots of base > classes (UserList, MutableSequence, Sequence ) etc and some mutating > methods might be inherited from those. I'll also have to do this for > UserDict (which is a MutableMapping, which is a Mapping). > > Is there a way to easily find out which methods of are mutating the > collection? Other than going over the source and checking all (normal > and inherited) methods? How about set(dir(collections.UserList)) - set(dir(collections.Sequence)) > And finally: set is a built in container type, but we don't have a > UserSet in collections. Was it ever proposed to be added to collections? I thought it was the other way round and UserList/UserDict were only kept for backwards-compatibility, but don't find anything in the docs to support this... -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Op 09-06-16 om 09:36 schreef Steven D'Aprano: > On Wednesday 08 June 2016 19:41, Antoon Pardon wrote: > >>> What you seem to be describing is similar to reference parameter semantics >>> from Pascal. Assignment doesn't work that way in C, or Python. >> I disagree. In python the assignment does work similar to the reference >> parameter semantics in pascal. See the following >> >> A = range[4] >> B = A >> B[2] = 5 >> print A # [0, 1, 5, 2] >> >> This is exactly the result you would get with B as a reference parameter in >> pascal. > It might be the same result, but it is a different cause. > > Your example demonstrates object mutation, not assignment. Generally assignment and mutation don't contradict each other. So IMO the cause is the same, a mutation. In some languages you can mutate your variable through an assignment and in others you can't. > But since you think that assignment in Python behaves like Pascal var > parameters (reference variables), you should be able to write a "swap" > procedure that swaps two arguments. That's the definitive test for reference > parameters, since it works in all languages with reference parameters (e.g. > Pascal, Basic and C++), and doesn't work in any language without them (or > equivalent, like Algol's pass-by-name parameters). It works in those languages because their the assignment mutates the variable that is assigned to. It is the fact that one can mutate a variable through an alias that makes it a reference variable, that is how it was already used in smalltalk. So because in python assignments don't mutate, you can't write a "swap" procedure in python, but AFAIR neither could you in smalltalk. You are confusing what it is that makes something a reference, with how an assignment can have an effect on a reference. It makes no sense to expect you can do the same with reference assignments as you can do with mutating assignments. > That is my challenge to you: if you can write such a function, in pure > Python, > which swaps two parameters given as ordinary arguments (passing their names > as > strings does not count), then I will cheerfully apologise for doubting you, > admit that I was wrong, and publicly acknowledge that Python does have > reference variables just like you said. > > If you cannot meet that challenge, then I would like you to acknowledge that > whatever Python variables are, and however Python's assignment works, it is > *not* the same as Pascal's reference variables, and so calling Python > variables > "reference variables" is misleading and an abuse of a well-established term > from computer science since long before Python even existed. Your challenge, shows that you don't fully understand what reference variables are. The behaviour you see in Pascal, doesn't depend (alone) on the parameter being a reference parameter. It also depends on the fact that the assignment in pascal mutates the variable that is assigned to. Variables are references if they are aliases, so that if you mutate through one alias, the mutation is visible through other aliases. So your challenge comes down to expecting me to mutate something by means that in python don't allow mutation. > Are you willing to accept that challenge? > > Or are you going to try to weasel out of it by changing the definition of > reference parameter to mean "whatever I want it to mean to avoid admitting I > was wrong"? I am using reference as it was already use by smalltalk. > >> It is true that you can't get such an effect in python, but that doesn't >> imply that python doesn't have reference variables (as an abstract notion). >> Because having reference variables doesn't imply you can have that effect. > Ah, well that answers that question. Weasel out it is. That is presuming you have the right understanding. -- https://mail.python.org/mailman/listinfo/python-list
Re: what is wrong with this property setter
Nagy László Zsolt wrote: > >>> Yes, and more. That property will also have a get method! Is it >>> intentional? >> It's a logical effect of how the setter() method works. The above is >> syntactic sugar for >> >> def set_parent(...): >>... >> set_parent = parent.setter(set_parent) >> >> and parent.setter() creates a new property basically like this >> >> def setter(self, fset): >> return property(self.fget, fset, ...) > This I could not find, because property is a built-in. But I believe > you. :-) If you can read C: https://hg.python.org/cpython/file/tip/Objects/descrobject.c#l1183 https://hg.python.org/cpython/file/tip/Objects/descrobject.c#l1265 -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Op 09-06-16 om 11:10 schreef BartC: > On 09/06/2016 08:50, Antoon Pardon wrote: >> Op 08-06-16 om 19:29 schreef BartC: >>> I don't see why we should determine what a /proper/ reference can do, based on what it does in one specific language. >>> >>> Because there are some things that such references can do that Python >>> can't do with its object reference model, not without some difficulty >>> or having to write convoluted code. >> >> So? Maybe you have the wrong idea of what a reference is/can do? > > Maybe. Maybe in all the languages I've been implementing for three > decades have implemented references and pointers wrongly. Then I assume you haven't heard of smalltalk. > Well, all my implementations of references and pointers meet Steven > D'Apranso' swap() challenge (see his post in this thread about 90 > minutes before this one). Yes and that seems to confuses assignments with mutations. The swap challenge is based on the assumptions that assignment mutates. You and Steven are expecting particular behaviour from the assignment that is acutually depending on behaviour that mutates. So if the assignment doesn't mutate, you can't expect that behaviour from an assignment. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Antoon Pardon :
> Your challenge, shows that you don't fully understand what reference
> variables are. The behaviour you see in Pascal, doesn't depend (alone)
> on the parameter being a reference parameter. It also depends on the
> fact that the assignment in pascal mutates the variable that is
> assigned to. Variables are references if they are aliases, so that if
> you mutate through one alias, the mutation is visible through other
> aliases. So your challenge comes down to expecting me to mutate
> something by means that in python don't allow mutation.
I think bringing Pascal in this discussion is only confusing matters.
Let me repeat the abstract Python data model I gave a couple of days
back:
- there are labeled *pegs* ("variables")
- there are *puppies* ("objects")
- each peg has one *leash* hanging from it
- each leash is tied to a puppy
- each puppy can have zero one or more leashes tied to it
- some puppies can hold leashes in their *mouths*
- some puppies can take hold of new leashes and let go of leashes
I'm not joking. Everybody is arguing about preconceived notions tied to
terminology. The peg-leash-puppy model is accurate and extensive.
We can now give semantics to Python's execution model. For example,
- every rvalue expression evaluates to a leash
- the lvalue expression identifies a peg or a mouth
- the assignment statement hangs a leash on a peg or in a mouth
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: OrderedDict
On Friday, May 20, 2016 at 7:15:38 AM UTC+2, [email protected] wrote: > On Wednesday, May 18, 2016 at 2:25:16 PM UTC+2, Peter Otten wrote: > > Chris Angelico wrote: > > > > > On Wed, May 18, 2016 at 7:28 PM, Peter Otten <[email protected]> wrote: > > >> I don't see an official way to pass a custom dict type to the library, > > >> but if you are not afraid to change its source code the following patch > > >> will allow you to access the value of dictionaries with a single entry as > > >> d[0]: > > >> > > >> $ diff -u py2b_xmltodict/local/lib/python2.7/site-packages/xmltodict.py > > >> py2_xmltodict/local/lib/python2.7/site-packages/xmltodict.py > > >> --- py2b_xmltodict/local/lib/python2.7/site-packages/xmltodict.py > > >> 2016-05-18 11:18:44.0 +0200 > > >> +++ py2_xmltodict/local/lib/python2.7/site-packages/xmltodict.py > > >> 2016-05-18 11:11:13.417665697 +0200 @@ -35,6 +35,13 @@ > > >> __version__ = '0.10.1' > > >> __license__ = 'MIT' > > >> > > >> +_OrderedDict = OrderedDict > > >> +class OrderedDict(_OrderedDict): > > >> +def __getitem__(self, key): > > >> +if key == 0: > > >> +[result] = self.values() > > >> +return result > > >> +return _OrderedDict.__getitem__(self, key) > > >> > > >> class ParsingInterrupted(Exception): > > >> pass > > > > > > Easier than patching might be monkeypatching. > > > > > > class OrderedDict(OrderedDict): > > > ... getitem code as above ... > > > xmltodict.OrderedDict = OrderedDict > > > > > > Try it, see if it works. > > > > It turns out I was wrong on (at least) two accounts: > > > > - xmltodict does offer a way to specify the dict type > > - the proposed dict implementation will not solve the OP's problem > > > > Here is an improved fix which should work: > > > > > > $ cat sample.xml > > > > > > > > > > > > > > $ cat sample2.xml > > > > > > > > > > > > > > > > $ cat demo.py > > import collections > > import sys > > import xmltodict > > > > > > class MyOrderedDict(collections.OrderedDict): > > def __getitem__(self, key): > > if key == 0 and len(self) == 1: > > return self > > return super(MyOrderedDict, self).__getitem__(key) > > > > > > def main(): > > filename = sys.argv[1] > > with open(filename) as f: > > doc = xmltodict.parse(f.read(), dict_constructor=MyOrderedDict) > > > > print "doc:\n{}\n".format(doc) > > print "package-id: {}".format( > > doc['profiles']['profile']['package'][0]['@package-id']) > > > > > > if __name__ == "__main__": > > main() > > $ python demo.py sample.xml > > doc: > > MyOrderedDict([(u'profiles', MyOrderedDict([(u'profile', > > MyOrderedDict([(u'@id', u'visio02'), (u'@revision', u'2015051501'), > > (u'package', MyOrderedDict([(u'@package-id', u'0964-gpg4win')]))]))]))]) > > > > package-id: 0964-gpg4win > > $ python demo.py sample2.xml > > doc: > > MyOrderedDict([(u'profiles', MyOrderedDict([(u'profile', > > MyOrderedDict([(u'@id', u'visio02'), (u'@revision', u'2015051501'), > > (u'package', [MyOrderedDict([(u'@package-id', u'0964-gpg4win')]), > > MyOrderedDict([(u'@package-id', u'0965-gpg4win')])])]))]))]) > > > > package-id: 0964-gpg4win > > I have tested the first solution. Works nice. Before I used xml.etree to > parse 2000 xml files. > > Execution time decrease from more then 5 min to 20 sec. Great. On weekend I > will test the solution with the own class. > > Many thanks. Hi all, tests with solution with the own class successful. Nice inspiration. I use this solution in my django script. Many thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Marko Rauhamaa writes: > Antoon Pardon : > >> You can do something like that in simula, but only because >> simula has two kinds of assignments. One kind that is >> simular to python and one that is similar to C. >> The one that is similar that python is the reference assignment. > > I see Python as doing the exact same thing with variables as C. I'm not sure that's a good mental model of what's going on. A variable declaration in C carries semantics of memory allocation to hold the value. This isn't so in python > > What is different is that in Python, every expression evaluates to a > pointer. Thus, you can only assign pointers to variables. > I don't think that's really right - every expression evaluates to an object. Whether or not that object can be accessed through some variable or not depends on how the expression is used. -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Op 09-06-16 om 11:19 schreef Marko Rauhamaa: > >> In a rather straight forward environment with classes/structs that >> have an x and y attribute, the following lines behave differently >> in C and Python. >> >> A.x = 1; >> A.y = 2; >> >> B = A; >> >> B.x = 3; >> B.y = 4; >> >> In C the variable A will still be x:1, y:2. >> In Python the variable A will be x:3, y:4. >> >> So no, Python doesn't do the exact same thing with variables as C. > The difference is not in the variables but in the expressions. In > Python, > > 1 > > evaluates to a pointer; in C, it evaluates to an int. Furthermore, in > Python, > > A > > evaluates to a pointer; in C, it evaluates to a struct. If a variable evaluates to something different, in different languages, the variable don't do the exact same thing in the different languages. -- https://mail.python.org/mailman/listinfo/python-list
Re: UserList - which methods needs to be overriden?
>> Is there a way to easily find out which methods of are mutating the >> collection? Other than going over the source and checking all (normal >> and inherited) methods? > How about > > set(dir(collections.UserList)) - set(dir(collections.Sequence)) Thanks. It narrows down the list of possible methods to be examined. > I thought it was the other way round and UserList/UserDict were only kept > for backwards-compatibility, but don't find anything in the docs to support > this... Are you saying that for any new project, I should subclass from list and dict, instead of UserList and UserDict? -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
On 09/06/2016 11:03, Marko Rauhamaa wrote:
Antoon Pardon :
Your challenge, shows that you don't fully understand what reference
variables are. The behaviour you see in Pascal, doesn't depend (alone)
on the parameter being a reference parameter. It also depends on the
fact that the assignment in pascal mutates the variable that is
assigned to. Variables are references if they are aliases, so that if
you mutate through one alias, the mutation is visible through other
aliases. So your challenge comes down to expecting me to mutate
something by means that in python don't allow mutation.
I think bringing Pascal in this discussion is only confusing matters.
Let me repeat the abstract Python data model I gave a couple of days
back:
- there are labeled *pegs* ("variables")
- there are *puppies* ("objects")
- each peg has one *leash* hanging from it
- each leash is tied to a puppy
- each puppy can have zero one or more leashes tied to it
- some puppies can hold leashes in their *mouths*
- some puppies can take hold of new leashes and let go of leashes
I'm not joking. Everybody is arguing about preconceived notions tied to
terminology. The peg-leash-puppy model is accurate and extensive.
We can now give semantics to Python's execution model. For example,
- every rvalue expression evaluates to a leash
- the lvalue expression identifies a peg or a mouth
- the assignment statement hangs a leash on a peg or in a mouth
And to implement swap() you need a leash that can be tied to a peg.
(Here, I'm assuming 'hanging from' and 'tied to' suggest that a leash is
uni-directional. But it's possible to imagine that a different part of a
peg is used to hang an out-going leash, compared to tying an incoming
one. Just like the puppies have necks to tie incoming leashes to (via
collars to avoid cruelty) and mouths for out-going ones.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
On 09/06/2016 10:55, Antoon Pardon wrote: Op 09-06-16 om 11:10 schreef BartC: On 09/06/2016 08:50, Antoon Pardon wrote: Op 08-06-16 om 19:29 schreef BartC: I don't see why we should determine what a /proper/ reference can do, based on what it does in one specific language. Because there are some things that such references can do that Python can't do with its object reference model, not without some difficulty or having to write convoluted code. So? Maybe you have the wrong idea of what a reference is/can do? Maybe. Maybe in all the languages I've been implementing for three decades have implemented references and pointers wrongly. Then I assume you haven't heard of smalltalk. Well, all my implementations of references and pointers meet Steven D'Apranso' swap() challenge (see his post in this thread about 90 minutes before this one). Yes and that seems to confuses assignments with mutations. The swap challenge is based on the assumptions that assignment mutates. You and Steven are expecting particular behaviour from the assignment that is acutually depending on behaviour that mutates. So if the assignment doesn't mutate, you can't expect that behaviour from an assignment. What does it matter? If swap() can be implemented via such a function, then it means that the language has such capability, which can be useful in different scenarios. If it can't, then the language hasn't. Python doesn't have it so it can't implement swap like that. There's no need to bring references into it at all. (A good thing as I've lost track of what it is you are arguing about! Are you staying references exist or they don't, that Python has them or it hasn't, or what? Meanwhile those of us of who sometimes have to implement these things can just get on with it.) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
On 09/06/2016 10:46, Antoon Pardon wrote: Op 09-06-16 om 09:36 schreef Steven D'Aprano: Your example demonstrates object mutation, not assignment. Generally assignment and mutation don't contradict each other. So IMO the cause is the same, a mutation. In some languages you can mutate your variable through an assignment and in others you can't. I think this is what is confusing you. Mutation is like repairing or customising my car. Full assignment is like buying a new car. The two are very different, even though they might involve the same "=" operator. Python object references work like the registration (license) plate on a car. Whatever you do via that, it will be the same car. Full references require the address of the house. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
why it is like stop running after a 3 seconds
i write a program, it is like forever loop
but i only restrict it to run 2 level recursively,
why it is slow, where is the problem?
M1 = {}
M2 = {}
M3 = {}
M4 = {}
M5 = {}
V6 = {}
M1['00']=0
M1['01']=1
M1['02']=1
M1['10']=2
M1['11']=2
M1['12']=1
M1['20']=1
M1['21']=2
M1['22']=1
M2['00']=0
M2['01']=1
M2['02']=2
M2['10']=1
M2['11']=2
M2['12']=1
M2['20']=1
M2['21']=1
M2['22']=1
M3['00']=0
M3['01']=2
M3['02']=2
M3['10']=1
M3['11']=2
M3['12']=1
M3['20']=0
M3['21']=1
M3['22']=0
M4['00']=2
M4['01']=2
M4['02']=0
M4['10']=2
M4['11']=1
M4['12']=2
M4['20']=0
M4['21']=1
M4['22']=2
M5['00']=0
M5['01']=1
M5['02']=2
M5['10']=1
M5['11']=1
M5['12']=1
M5['20']=1
M5['21']=1
M5['22']=2
V6['00']=1
V6['01']=2
V6['02']=1
V6['10']=2
V6['11']=1
V6['12']=1
V6['20']=2
V6['21']=2
V6['22']=0
MM = {}
MM[0] = M1
MM[1] = M2
MM[2] = M3
MM[3] = M4
MM[4] = M5
MM[5] = V6
m = 3
b = [str(i)+str(j)+str(k) for i in range(m) for j in range(m) for k in range(m)]
import itertools
deep = 3
final = []
mylist = [MM[i] for i in range(0,7-1)]
b = [str(i)+str(j)+str(k) for i in range(m) for j in range(m) for k in range(m)]
def DFS(b, deep, maxx, sourceoperators, path):
initlist = []
if deep > 0:
print("deep=", deep)
for aa,bb in itertools.combinations(sourceoperators, 2):
print(aa,bb)
if deep == maxx:
finalresult = []
op1xy = [aa[b[i][0:1]+b[i][1:2]] for i in range(len(b))]
op1yz = [aa[b[i][1:2]+b[i][2:3]] for i in range(len(b))]
op1xz = [aa[b[i][0:1]+b[i][2:3]] for i in range(len(b))]
op2xy = [bb[b[i][0:1]+b[i][1:2]] for i in range(len(b))]
op2yz = [bb[b[i][1:2]+b[i][2:3]] for i in range(len(b))]
op2xz = [bb[b[i][0:1]+b[i][2:3]] for i in range(len(b))]
if sum(op1xy) == 54:
path.append([(deep, aa, "xy")])
if sum(op1yz) == 54:
path.append([(deep, aa, "yz")])
if sum(op1xz) == 54:
path.append([(deep, aa, "xz")])
if sum(op2xy) == 54:
path.append([(deep, bb, "xy")])
if sum(op2yz) == 54:
path.append([(deep, bb, "yz")])
if sum(op2xz) == 54:
path.append([(deep, bb, "xz")])
initlist.append(op1xy)
initlist.append(op1yz)
initlist.append(op1xz)
initlist.append(op2xy)
initlist.append(op2yz)
initlist.append(op2xz)
else:
level = []
for j in range(len(b)):
op1xy = [aa[b[j][i]] for i in range(len(b[j]))]
op2xy = [bb[b[j][i]] for i in range(len(b[j]))]
if sum(op1xy) == 54:
path.append([(deep, aa, "xy")])
if sum(op2xy) == 54:
path.append([(deep, bb, "xy")])
level.append(op1xy)
level.append(op2xy)
initlist.append(op1xy)
initlist.append(op2xy)
if deep == maxx:
b = []
for aaa,bbb in itertools.combinations(initlist, 2):
b.append([str(i)+str(j) for i,j in zip(aaa, bbb)])
path = DFS(b, deep-1, maxx, sourceoperators, path)
else:
for aaa,bbb in itertools.combinations(initlist, 2):
b.append([str(i)+str(j) for i,j in zip(aaa, bbb)])
path = DFS(b, deep-1, maxx, sourceoperators, path)
return path
path = []
mresult = DFS(b, 2, 2, mylist, path)
--
https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
BartC writes: > On 09/06/2016 10:46, Antoon Pardon wrote: >> Op 09-06-16 om 09:36 schreef Steven D'Aprano: > >>> Your example demonstrates object mutation, not assignment. >> >> Generally assignment and mutation don't contradict each other. >> So IMO the cause is the same, a mutation. In some languages you >> can mutate your variable through an assignment and in others you >> can't. > > I think this is what is confusing you. > > Mutation is like repairing or customising my car. > > Full assignment is like buying a new car. Nice. [- -] -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Op 09-06-16 om 12:48 schreef BartC: > > What does it matter? > > If swap() can be implemented via such a function, then it means that > the language has such capability, which can be useful in different > scenarios. > > If it can't, then the language hasn't. > > Python doesn't have it so it can't implement swap like that. > > There's no need to bring references into it at all. Whether a language can implement a swap procedure like that is not the same question as whether the language variables are references or not. Since the topic was whether or not python has reference variables, is seems there is no need to bring this swap procedure into it at all, instead of turning it around and pretending it was about the swap procedure. -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Op 09-06-16 om 12:53 schreef BartC: > On 09/06/2016 10:46, Antoon Pardon wrote: >> Op 09-06-16 om 09:36 schreef Steven D'Aprano: > >>> Your example demonstrates object mutation, not assignment. >> >> Generally assignment and mutation don't contradict each other. >> So IMO the cause is the same, a mutation. In some languages you >> can mutate your variable through an assignment and in others you >> can't. > > I think this is what is confusing you. > > Mutation is like repairing or customising my car. > > Full assignment is like buying a new car. I think you are confused. Full assignment of C struct or Pascal record is the same as mutating all individual attributes. You don't get a new record/instance as in Python. You replace the value of the attributes with something else. As far a language semantics are concerned, you get the (new) car at scope entry, all assigments later are mutations. You may think of assignment as like buying a new car, that is not how the semantics of languages like pascal and C are defined. -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Antoon Pardon wrote: > A.x = 1; > A.y = 2; > > B = A; > > B.x = 3; > B.y = 4; > > > In C the variable A will still be x:1, y:2. > In Python the variable A will be x:3, y:4. But it would, if you had written instead: A->x = 1; A->y = 2; B = A; B->x = 3; B->y = 4; which backs indeed the C pointer analogy... -- Julien Salort Entia non sunt multiplicanda praeter necessitatem http://www.juliensalort.org -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
On 09/06/2016 12:19, Antoon Pardon wrote: Op 09-06-16 om 12:53 schreef BartC: On 09/06/2016 10:46, Antoon Pardon wrote: Op 09-06-16 om 09:36 schreef Steven D'Aprano: Your example demonstrates object mutation, not assignment. Generally assignment and mutation don't contradict each other. So IMO the cause is the same, a mutation. In some languages you can mutate your variable through an assignment and in others you can't. I think this is what is confusing you. Mutation is like repairing or customising my car. Full assignment is like buying a new car. I think you are confused. Full assignment of C struct or Pascal record is the same as mutating all individual attributes. You don't get a new record/instance as in Python. You replace the value of the attributes with something else. As far a language semantics are concerned, you get the (new) car at scope entry, all assigments later are mutations. You may think of assignment as like buying a new car, that is not how the semantics of languages like pascal and C are defined. Static languages like C and Pascal don't make for a good comparison. C is just too low level: anything is possible so can be twisted any way. A bit like assembly. C variables have a fixed type, which you can't change by assignment (so a Ford can't change to a different marque). But being low-level, assignment in C is just copying N bytes from A to B. Which is also what happens when, instead of copying a whole struct, you mutate all of it by assigning the fields one by one. Python assignments are bit more sophisticated, and there are real differences between full assignment (where a variable ends up with a different object reference) and mutation (where it might be the same, but modified, object). -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
On 09/06/2016 12:08, Antoon Pardon wrote: Op 09-06-16 om 12:48 schreef BartC: What does it matter? If swap() can be implemented via such a function, then it means that the language has such capability, which can be useful in different scenarios. If it can't, then the language hasn't. Python doesn't have it so it can't implement swap like that. There's no need to bring references into it at all. Whether a language can implement a swap procedure like that is not the same question as whether the language variables are references or not. Now /you're/ turning it around. I'm not interested in the internal references that Python currently uses. (I've called them /object references/.) I'm talking about a different kind of reference, possible /name references/, they would make possible new things Since the topic was whether or not python has reference variables, is seems there is no need to bring this swap procedure into it at all, instead of turning it around and pretending it was about the swap procedure. ... such as implementing a function that can exchange the values of its caller's two arguments. In bytecode, Python might need to swap variables using: load a load b store a store b (which can get inefficient if swapping a[i+j-1] and b[j-i+1]). A name reference would allow: loadref a loadref b swap -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Tie dictionary to database table?
In Perl there exists the tie mechanism for key/value type databases like Berkeley db. Are there any python modules that can do the same for a column of a mysql table? Given the following table users: ( username char(16) not null unique, email char(128), fullname char(64) ) What I would like is if I write email['frank']='[email protected]' in my python script it generates a statement like update users set email='[email protected]' where username='frank'; Any hints to already existing modules are highly appreciated. and have -- Dipl.-Inform(FH) Peter Heitzer, [email protected] -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Op 09-06-16 om 13:46 schreef Julien Salort: > Antoon Pardon wrote: > >> A.x = 1; >> A.y = 2; >> >> B = A; >> >> B.x = 3; >> B.y = 4; >> >> >> In C the variable A will still be x:1, y:2. >> In Python the variable A will be x:3, y:4. > But it would, if you had written instead: > > A->x = 1; > A->y = 2; > > B = A; > > B->x = 3; > B->y = 4; > > which backs indeed the C pointer analogy... Yes, what is your point? I know there is a C pointer analogy with Python variables. The fact that there is an analogy between C pointers and Python variables, is not enough to conclude that C variables and Python variables behave exactly the same. Normal structs are a kind of variable too in C. If you have to ignore those in order to show similarities, then the variables in general don't behave exactly the same. -- https://mail.python.org/mailman/listinfo/python-list
google sheet and google app engine(GAE) python
how do connect my google sheet and my GAE application made in python so that i can read , update and delete cells , any step by instruction for newbie? -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Op 09-06-16 om 14:25 schreef BartC: > On 09/06/2016 12:08, Antoon Pardon wrote: >> Op 09-06-16 om 12:48 schreef BartC: >>> >>> What does it matter? >>> >>> If swap() can be implemented via such a function, then it means that >>> the language has such capability, which can be useful in different >>> scenarios. >>> >>> If it can't, then the language hasn't. >>> >>> Python doesn't have it so it can't implement swap like that. >>> >>> There's no need to bring references into it at all. >> >> Whether a language can implement a swap procedure like that is >> not the same question as whether the language variables are >> references or not. > > Now /you're/ turning it around. > > I'm not interested in the internal references that Python currently > uses. (I've called them /object references/.) > > I'm talking about a different kind of reference, possible /name > references/, they would make possible new things That you talk about something different, doesn't make others wrong when they use the label "reference" for what they are talking about. If someone writes that variables in python are references or reference variables, then there is an historical meaning for the label "reference" that makes this statement true. Protesting the statment because you think of something different when you read "reference", just means you didn't understand the original statement. -- https://mail.python.org/mailman/listinfo/python-list
Re: for / while else doesn't make sense
On 2016年05月19日 11時02分, Ian Kelly wrote: "else" makes sense from a certain point of view, but I think that logic may not be communicated well. At the start of each loop iteration, the loop construct makes a test for whether the loop should continue or not. If that test ever fails (i.e. if the condition of the while loop is false), the else block is executed instead. Thank you for the concise explanation. (I enjoy new tools.) As alluded to elsewhere, this distinction makes sense when loop breaking is involved. -- https://mail.python.org/mailman/listinfo/python-list
Re: UserList - which methods needs to be overriden?
Nagy László Zsolt wrote: > >>> Is there a way to easily find out which methods of are mutating the >>> collection? Other than going over the source and checking all (normal >>> and inherited) methods? >> How about >> >> set(dir(collections.UserList)) - set(dir(collections.Sequence)) > Thanks. It narrows down the list of possible methods to be examined. > >> I thought it was the other way round and UserList/UserDict were only kept >> for backwards-compatibility, but don't find anything in the docs to >> support this... > Are you saying that for any new project, I should subclass from list and > dict, instead of UserList and UserDict? Using the built-in list or dict is problematic because sometimes the subclass methods are ignored when the internal data is accessed (sorry, I don't have an example). I thought you should subclass MutableSequence instead of UserList, but I may have been wrong. While you minimize your effort -- just add methods until you can instantiate your subclass -- the resulting class will not be very efficient. How detailed is your change notification? If it's always the same method invocation you may be able to create wrappers like def whatever(self, *args): try: return super().whatever(*args) finally: self.changed() automatically, and the base class, be it list or UserList or whatever becomes a detail that can be chosen on a case by case basis. -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Op 09-06-16 om 14:17 schreef BartC: > On 09/06/2016 12:19, Antoon Pardon wrote: >> Op 09-06-16 om 12:53 schreef BartC: >>> On 09/06/2016 10:46, Antoon Pardon wrote: Op 09-06-16 om 09:36 schreef Steven D'Aprano: >>> > Your example demonstrates object mutation, not assignment. Generally assignment and mutation don't contradict each other. So IMO the cause is the same, a mutation. In some languages you can mutate your variable through an assignment and in others you can't. >>> >>> I think this is what is confusing you. >>> >>> Mutation is like repairing or customising my car. >>> >>> Full assignment is like buying a new car. >> >> I think you are confused. Full assignment of C struct or >> Pascal record is the same as mutating all individual >> attributes. You don't get a new record/instance as in >> Python. You replace the value of the attributes with >> something else. >> >> As far a language semantics are concerned, you get the >> (new) car at scope entry, all assigments later are >> mutations. >> >> You may think of assignment as like buying a new car, >> that is not how the semantics of languages like pascal >> and C are defined. > > Static languages like C and Pascal don't make for a good comparison. C > is just too low level: anything is possible so can be twisted any way. > A bit like assembly. But this "low" level is needed to make a swap work. > > C variables have a fixed type, which you can't change by assignment > (so a Ford can't change to a different marque). But being low-level, > assignment in C is just copying N bytes from A to B. Which is also > what happens when, instead of copying a whole struct, you mutate all > of it by assigning the fields one by one. Exactly and it is this mutating that makes a swap procedure possible in the languages that come up here. > > Python assignments are bit more sophisticated, and there are real > differences between full assignment (where a variable ends up with a > different object reference) and mutation (where it might be the same, > but modified, object). Yes and it is this difference that makes it impossible to write a swap procedure, despite the variables in python being reference variables. Make up what ever kind of reference you wil. If your assignment will only change references and won't mutate, you will not be able to write a swap procedure. -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Paul Rudin : > Marko Rauhamaa writes: >> What is different is that in Python, every expression evaluates to a >> pointer. Thus, you can only assign pointers to variables. > > I don't think that's really right - every expression evaluates to an > object. The object is only an intermediate result; what is returned is a pointer (to an object), without an exception. That's not a matter of implementation. It's an essential part of Python's data model. (However, since "pointer" is evokes passions among crowds, it is better to use the neutral word "leash".) Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Tie dictionary to database table?
It looks like you might be looking for an ORM. Have you checked out sqlalchemy? -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Antoon Pardon : > Op 09-06-16 om 11:19 schreef Marko Rauhamaa: >> The difference is not in the variables but in the expressions. In >> Python, >> >> 1 >> >> evaluates to a pointer; in C, it evaluates to an int. Furthermore, in >> Python, >> >> A >> >> evaluates to a pointer; in C, it evaluates to a struct. > > If a variable evaluates to something different, in different > languages, the variable don't do the exact same thing in > the different languages. In fact, it turns out that the variables are evaluated identically in both C and Python. In both cases, a variable evaluates to the value the variable is holding at the moment. However, since all Python expressions evaluate into pointers, there's no way to assign anything but a pointer to a variable. In C, expression evaluation is much more diverse, as is variable typing. Since Python variable is always holding a pointer, its straightforward evaluation results in a pointer, closing the circle. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Intel Distribution for Python
Intel has released Beta Update 1 of its Python distribution: "What's New! Jupyter* notebook interface Neural network APIs support for pyDAAL Optimized random number generation features for numpy.random package" -- https://mail.python.org/mailman/listinfo/python-list
Re: UserList - which methods needs to be overriden?
> Using the built-in list or dict is problematic because sometimes the
> subclass methods are ignored when the internal data is accessed (sorry, I
> don't have an example).
Are you suggesting that I should use UserList and UserDict instead of
list and dict? What is the truth? Was UserDict left in collections for
backward compatibility, or not?
>
> How detailed is your change notification? If it's always the same method
> invocation you may be able to create wrappers like
>
> def whatever(self, *args):
> try:
> return super().whatever(*args)
> finally:
> self.changed()
>
> automatically, and the base class, be it list or UserList or whatever
> becomes a detail that can be chosen on a case by case basis.
My actual solution looks like this:
class ObservableCollection(Observable):
@contextmanager
def notify(self):
self.notify_observers(EVT_BEFORE_COLLECTION_CHANGED)
yield
self.notify_observers(EVT_AFTER_COLLECTION_CHANGED)
class ObservableList(ObservableCollection, list):
__slots__ = []
def remove(self, value):
with self.notify(): super().remove(value)
def clear(self):
with self.notify(): super().clear()
def pop(self):
with self.notify(): return super().pop()
It seems to be working with the built in list, dict and set types.
There must be a better way! Something like this:
@wrap_notify('remove', 'clear', 'append', 'insert', 'sort'):
class ObservableList(ObservableCollection, list):
pass
I just can't find out the right syntax.
--
https://mail.python.org/mailman/listinfo/python-list
Re: run code error with numpy and scipy
On 2016-06-09 07:02, meInvent bbird wrote: when i run code in window has an error not a valid win32 dll then i install scipy first in this site, then install numpy-mkl all python 2.7 and win32 http://www.lfd.uci.edu/~gohlke/pythonlibs/ then i run code below, got error , and captured screen in this link https://drive.google.com/file/d/0Bxs_ao6uuBDUQXROd2VqSURGa00/view?usp=sharing [snip] You're entering it at the interactive Python prompt. When it sees the blank line, it thinks you've finished entering the function, so it complains when the next line is indented. (Things are slightly different when working interactively than when running from a file.) You should put the code into a file and then run that. -- https://mail.python.org/mailman/listinfo/python-list
Re: UserList - which methods needs to be overriden?
> @wrap_notify('remove', 'clear', 'append', 'insert', 'sort'):
> class ObservableList(ObservableCollection, list):
> pass
>
> I just can't find out the right syntax.
>
>
All right, this is working.
from contextlib import contextmanager
class ObservableCollection:
@contextmanager
def notify(cls):
print("notify before change")
yield
print("notify after change")
def wrap_notify(cls, basecls, method_names):
for method_name in method_names:
orig = getattr(basecls, method_name)
def modified(self, *args, **kwargs):
with self.notify(): return orig(self,*args,**kwargs)
setattr(cls, method_name, modified)
return cls
class ObservableDict(ObservableCollection, dict):
__slots__ = []
wrap_notify(ObservableDict, dict, ['update', '__delitem__',
'__setitem__']) # many others...
class ObservableList(ObservableCollection, list):
__slots__ = []
wrap_notify(ObservableList, list, ['append', 'pop']) # many others...
d = ObservableDict()
d[1] = 2
print(d)
But I'm still not 100% satisfied. wrap_notify is not a class decorator.
Is there a way to make a class decorator that gets the class as its
first parameter? It would be very nice:
def wrap_notify(cls, method_names):
class Wrapped(cls):
pass
for method_name in method_names:
orig = getattr(Wrapped, method_name)
def modified(self, *args, **kwargs):
with self.notify(): return orig(self,*args,**kwargs)
setattr(cls, method_name, modified)
return Wrapped
@wrap_notify(['update', '__delitem__', '__setitem__']) # many others...
class ObservableDict(ObservableCollection, dict):
__slots__ = []
@wrap_notify(['append', 'pop']) # many others...
class ObservableList(ObservableCollection, list):
__slots__ = []
And finally: is this Pythonic, or a horrible mess? Would it be better to
duplicate the body of each method one by one?
--
https://mail.python.org/mailman/listinfo/python-list
RE: Design an encrypted time-limited API on Client/Server side
> I am planning design an encrypted time-limited API on both Client and Server > sides, If you want client/server communitation in an encypted way you can use the ssl module. This email is confidential and may be subject to privilege. If you are not the intended recipient, please do not copy or disclose its content but contact the sender immediately upon receipt. -- https://mail.python.org/mailman/listinfo/python-list
Re: UserList - which methods needs to be overriden?
Nagy László Zsolt wrote:
>
>> Using the built-in list or dict is problematic because sometimes the
>> subclass methods are ignored when the internal data is accessed (sorry, I
>> don't have an example).
> Are you suggesting that I should use UserList and UserDict instead of
> list and dict? What is the truth? Was UserDict left in collections for
> backward compatibility, or not?
>
>>
>> How detailed is your change notification? If it's always the same method
>> invocation you may be able to create wrappers like
>>
>> def whatever(self, *args):
>> try:
>> return super().whatever(*args)
>> finally:
>> self.changed()
>>
>> automatically, and the base class, be it list or UserList or whatever
>> becomes a detail that can be chosen on a case by case basis.
> My actual solution looks like this:
>
>
> class ObservableCollection(Observable):
> @contextmanager
> def notify(self):
> self.notify_observers(EVT_BEFORE_COLLECTION_CHANGED)
> yield
> self.notify_observers(EVT_AFTER_COLLECTION_CHANGED)
>
> class ObservableList(ObservableCollection, list):
> __slots__ = []
>
> def remove(self, value):
> with self.notify(): super().remove(value)
>
> def clear(self):
> with self.notify(): super().clear()
>
> def pop(self):
> with self.notify(): return super().pop()
>
> It seems to be working with the built in list, dict and set types.
>
> There must be a better way! Something like this:
>
> @wrap_notify('remove', 'clear', 'append', 'insert', 'sort'):
> class ObservableList(ObservableCollection, list):
> pass
>
> I just can't find out the right syntax.
[Looks like you made progress while I struggled to come up with the
following. I'll post it anyway.]
$ cat observable_list.py
from contextlib import contextmanager
EVT_BEFORE_COLLECTION_CHANGED = "EVT_BEFORE_COLLECTION_CHANGED"
EVT_AFTER_COLLECTION_CHANGED = "EVT_AFTER_COLLECTION_CHANGED"
class Observable:
def notify_observers(self, message):
print(message)
def wrap_notify(*names):
def wrap_methods(cls):
for name in names:
method = wrap_method(getattr(cls, name), name)
setattr(cls, name, method)
return cls
return wrap_methods
def wrap_method(method, name):
def wrapped_method(self, *args, **kw):
with self.notify():
return method(self, *args, **kw)
return wrapped_method
class ObservableCollection(Observable):
@contextmanager
def notify(self):
self.notify_observers(EVT_BEFORE_COLLECTION_CHANGED)
yield
self.notify_observers(EVT_AFTER_COLLECTION_CHANGED)
@wrap_notify('remove', 'clear', 'append', 'insert', 'sort')
class ObservableList(ObservableCollection, list):
pass
items = ObservableList()
items.append(42)
items.append(41)
items.sort()
print(items)
$ python3 observable_list.py
EVT_BEFORE_COLLECTION_CHANGED
EVT_AFTER_COLLECTION_CHANGED
EVT_BEFORE_COLLECTION_CHANGED
EVT_AFTER_COLLECTION_CHANGED
EVT_BEFORE_COLLECTION_CHANGED
EVT_AFTER_COLLECTION_CHANGED
[41, 42]
--
https://mail.python.org/mailman/listinfo/python-list
EuroPython 2016 Keynotes
We are pleased to announce our keynote schedule for EuroPython 2016: * Monday: Rachel Willmer & Nicholas Tollervey * Tuesday: Paul Hildebrandt * Wednesday: Jameson Rollins * Thursday: Naomi Ceder * Friday: Gaël Varoquaux More information about our keynoters is available on the keynote schedule page and the blog posts for each keynote: *** EuroPython 2016 Keynotes *** https://ep2016.europython.eu/en/events/keynotes/ We have also updated the schedule accordingly: *** EuroPython 2016 Schedule *** https://ep2016.europython.eu/p3/schedule/ep2016/ With gravitational regards, -- EuroPython 2016 Team http://ep2016.europython.eu/ http://www.europython-society.org/ PS: Please forward or retweet to help us reach all interested parties: https://twitter.com/europython/status/740868506862915584 Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Marko Rauhamaa writes: > Paul Rudin : > >> Marko Rauhamaa writes: >>> What is different is that in Python, every expression evaluates to a >>> pointer. Thus, you can only assign pointers to variables. >> >> I don't think that's really right - every expression evaluates to an >> object. > > The object is only an intermediate result; what is returned is a pointer > (to an object), without an exception. That's not a matter of > implementation. It's an essential part of Python's data model. > Well - the language has no explicit notion of "pointer", so I'm not sure it's really correct to say that it's an essential part of the data model. The way variables are used to reference the objects associated with them from time to time has some similarities with pointer semantics in other languages. But actually it's better (IMO) to just talk in the terms the language specification uses. There are names and objects, and mechanisms by which names come to refer to objects according to the execution model. > (However, since "pointer" is evokes passions among crowds, it is better > to use the neutral word "leash".) Talk of pointers is potentially confusing, because it carries baggage from other languages which doesn't necessary map precisely onto the python execution model. (The underlying cpython implementation, is neither here nor there - we could in theory implement python in some other language which lacks a pointer type.) -- https://mail.python.org/mailman/listinfo/python-list
Re: Want to play with or learn a parser system including a grammar for Python? See spark_parser on pypy
On Wednesday, June 8, 2016 at 10:39:00 PM UTC+12, rocky wrote: > In addition to the example programs which give the classic arithmetic > expression evaluator, I now include the beginnings of a full Python 2.6 > language. Does anybody bother with LR(k) parsers any more? -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Paul Rudin : > Marko Rauhamaa writes: >> The object is only an intermediate result; what is returned is a >> pointer (to an object), without an exception. That's not a matter of >> implementation. It's an essential part of Python's data model. > > Well - the language has no explicit notion of "pointer", [...] it's > better (IMO) to just talk in the terms the language specification > uses. The spec (https://docs.python.org/3/reference/datamodel.html>) uses the terms *identity* and *reference*, which are one-to-one. > There are names and objects, and mechanisms by which names come to > refer to objects according to the execution model. The spec as well as Python itself uses the word "name" for various strings: >>> "x".__class__.__name__ 'str' >>> __name__ '__main__' So your "names" are *variables*. Your "mechanisms" are *references*. Your "objects" are *objects*. > Talk of pointers is potentially confusing, because it carries baggage > from other languages which doesn't necessary map precisely onto the > python execution model. Unfortunately, virtually every word is overloaded and full of preconceived notions. Hence: "pegs", "leashes", "puppies". The main thing is to keep those three concepts apart from each other. Two notions will not suffice. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: movie from pictures
Thank you for your reply. I tried something like this in python code: from subprocess import call call(["ffmpeg -framerate 4/1 -start_number 1 -i C:\\Projects\\data2\\img_%05d.png -c:v libx264 -r 30 -pix_fmt yuv420p C:\\Projects\\data2\\movie.mp4"]) But it did not work. I get FileNotFoundError: [WinError 2] The system cannot find the file specified.. On the other hand, in-loop solution would be more preferable since it lets me to use variable names of the images and paths.. -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Marko Rauhamaa writes: > Paul Rudin : > >> Marko Rauhamaa writes: >>> The object is only an intermediate result; what is returned is a >>> pointer (to an object), without an exception. That's not a matter of >>> implementation. It's an essential part of Python's data model. >> >> Well - the language has no explicit notion of "pointer", [...] it's >> better (IMO) to just talk in the terms the language specification >> uses. > > The spec (https://docs.python.org/3/reference/datamodel.html>) > uses the terms *identity* and *reference*, which are one-to-one. identity isn't the same thing as a name, identity is an inherent property of an object - many names may refer to the same object. Similarly reference doesn't mean the same thing as identity. A reference to an object can occur, for example: ["foo"] The list refers to the string. There's no name involved anywhere. Both the list and the string have an identity, but that's essentially irrelevant to the fact that the list has a reference to the string. > >> There are names and objects, and mechanisms by which names come to >> refer to objects according to the execution model. > > The spec as well as Python itself uses the word "name" for various > strings: > >>>> "x".__class__.__name__ >'str' >>>> __name__ >'__main__' > __name__ is not the same thing as what the spec means when it talks of a name. It's certainly true that a class declaration creates a binding from that name to an object representing the class. But other names can equally well refer to the same object: >>> class Foo: ... pass ... >>> Bar = Foo >>> x = Bar() >>> x.__class__.__name__ 'Foo' >>> > > So your "names" are *variables*. Informally yes, but "variable" has no meaning in the language reference. > > Your "mechanisms" are *references*. > Nope - when I spoke of mechanisms I was talking about the different operational semantics by which a given names can be bound to an object. Once such an binding has occured then I agree that the name refers to the object in question. > Your "objects" are *objects*. > I think I probably agree, but I'm not sure what you're saying - "object" means something in the language reference - that's what I'm talking about. >> Talk of pointers is potentially confusing, because it carries baggage >> from other languages which doesn't necessary map precisely onto the >> python execution model. > > Unfortunately, virtually every word is overloaded and full of > preconceived notions. Hence: "pegs", "leashes", "puppies". > > The main thing is to keep those three concepts apart from each other. > Two notions will not suffice. > Well - adding more things is confusing in IMO - we have a language reference, let's just use the terms in the language reference. -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Paul Rudin writes: > Marko Rauhamaa writes: >> So your "names" are *variables*. > > Informally yes, but "variable" has no meaning in the language reference. > ... err sorry, actually not correct - but irrelevant to the point under discussion. -- https://mail.python.org/mailman/listinfo/python-list
Re: UserList - which methods needs to be overriden?
> [Looks like you made progress while I struggled to come up with the > following. I'll post it anyway.] Your version is much better. Thanks! :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: why it is like stop running after a 3 seconds
In <[email protected]> Ho Yeung Lee writes: > i write a program, it is like forever loop > but i only restrict it to run 2 level recursively, I don't think the restriction is working. There is "if deep > 0:" at the top of the function, but the recursive calls aren't inside that if block. DFS keeps calling itself with smaller and smaller values of deep. -- John Gordon A is for Amy, who fell down the stairs [email protected] B is for Basil, assaulted by bears -- Edward Gorey, "The Gashlycrumb Tinies" -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
On Thu, Jun 9, 2016, at 03:30, Antoon Pardon wrote: > Then you think wrong. Python has no pointers, that is an implementation > detail. Nonsense. A binary number referring to a memory address is an implementation detail. A pointer/reference/arrow-thingy-on-a-diagram is the thing it is an implementation detail *of*. -- https://mail.python.org/mailman/listinfo/python-list
Re: movie from pictures
Nev wrote: > Thank you for your reply. I tried something like this in python code: > > from subprocess import call > call(["ffmpeg -framerate 4/1 -start_number 1 -i > C:\\Projects\\data2\\img_%05d.png -c:v libx264 -r 30 -pix_fmt yuv420p > C:\\Projects\\data2\\movie.mp4"]) > > But it did not work. I get FileNotFoundError: [WinError 2] The system > cannot find the file specified.. You have to pass the command-line arguments as separate items in the list: call(["ffmpeg", "-framerate", "4/1", "-start_number", "1", "-i", "C:\\Projects\\data2\\img_%05d.png", ... # and so on ]) > On the other hand, in-loop solution would be more preferable since it lets > me to use variable names of the images and paths.. -- https://mail.python.org/mailman/listinfo/python-list
Re: movie from pictures
On 2016-06-09 19:58, Peter Otten wrote: Nev wrote: Thank you for your reply. I tried something like this in python code: from subprocess import call call(["ffmpeg -framerate 4/1 -start_number 1 -i C:\\Projects\\data2\\img_%05d.png -c:v libx264 -r 30 -pix_fmt yuv420p C:\\Projects\\data2\\movie.mp4"]) But it did not work. I get FileNotFoundError: [WinError 2] The system cannot find the file specified.. You have to pass the command-line arguments as separate items in the list: call(["ffmpeg", "-framerate", "4/1", "-start_number", "1", "-i", "C:\\Projects\\data2\\img_%05d.png", ... # and so on ]) You should also give it the full path of ffmpeg. On the other hand, in-loop solution would be more preferable since it lets me to use variable names of the images and paths.. -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Paul Rudin : > Marko Rauhamaa writes: >> The spec (https://docs.python.org/3/reference/datamodel.html>) >> uses the terms *identity* and *reference*, which are one-to-one. > > identity isn't the same thing as a name, identity is an inherent > property of an object - many names may refer to the same object. x is yif and only ifid(x) == id(y) However, sorry for muddling the discussion by bringing in the identity. I'll leave it out for now. >> So your "names" are *variables*. > > Informally yes, but "variable" has no meaning in the language reference. Really? How do you interpret these, then? Although the definition of assignment implies that overlaps between the left-hand side and the right-hand side are ‘simultaneous’ (for example a, b = b, a swaps two variables), overlaps within the collection of assigned-to variables occur left-to-right, sometimes resulting in confusion. https://docs.python.org/3/reference/simple_stmts.html?#assignme nt-statements> Assignments to __debug__ are illegal. The value for the built-in variable is determined when the interpreter starts. https://docs.python.org/3/reference/simple_stmts.html?#the-asse rt-statement> The public names defined by a module are determined by checking the module’s namespace for a variable named __all__ https://docs.python.org/3/reference/simple_stmts.html?#the-impo rt-statement> It would be impossible to assign to a global variable without global, although free variables may refer to globals without being declared global. https://docs.python.org/3/reference/simple_stmts.html?#the-glob al-statement> >> Unfortunately, virtually every word is overloaded and full of >> preconceived notions. Hence: "pegs", "leashes", "puppies". >> >> The main thing is to keep those three concepts apart from each other. >> Two notions will not suffice. > > Well - adding more things is confusing in IMO - we have a language > reference, let's just use the terms in the language reference. I have quoted "the language reference" quite a bit. Your turn. You would be correct that there is something of an faux elitism going around that is influencing the language spec as well to a degree. It appears some people consider "variables," "assignments," "pointers" etc to be too riff-raff. So people want to say Python is unlike C and has "names," "bindings," "references" etc. There's no shame in stating directly that Python has variables just like C even though Python's variables are not first-class. There's no difference between binding and assignment. And a reference is a synonym to a pointer. Python still has good stuff C doesn't, or even Java. Marko -- https://mail.python.org/mailman/listinfo/python-list
PyCon Keynote
There were many good talks and presentations at PyCon 2016, but if you can only watch one, this is the one to watch: https://www.youtube.com/watch?v=bSfe5M_zG2s -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: UserList - which methods needs to be overriden?
On Thu, Jun 9, 2016 at 5:07 AM Nagy László Zsolt
wrote:
> I would like to create a collections.UserList subclass that can notify
> others when the list is mutated.
>
Why not subclass MutableSequence instead? The ABC will tell you which
methods to override (the abstract ones). The mixin methods rely on those
overrides.
from collections.abc import MutableSequence
def noisy(message):
def decorator(func):
def wrapper(*args, **kwargs):
print(message)
return func(*args, **kwargs)
return wrapper
return decorator
class NoisyList(MutableSequence):
def __init__(self, *args, **kwargs):
self.contents = list(*args, **kwargs)
def __getitem__(self, index):
return self.contents[index]
def __len__(self):
return len(self.contents)
@noisy('set')
def __setitem__(self, index, value):
self.contents[index] = value
@noisy('del')
def __delitem__(self, index):
del self.contents[index]
@noisy('insert')
def insert(self, index, value):
self.contents.insert(index, value)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Tie dictionary to database table?
On Thu, Jun 9, 2016 at 9:10 AM justin walters wrote: > It looks like you might be looking for an ORM. Have you checked out > sqlalchemy? > An ORM might be overkill. If you just want a persistent dictionary, just use the shelve module. https://docs.python.org/3/library/shelve.html -- https://mail.python.org/mailman/listinfo/python-list
Re: which library has map reduce and how to use it for this case
I like using Yelp's mrjob module (https://github.com/Yelp/mrjob) to run Python on Hadoop. On Thu, Jun 9, 2016 at 2:56 AM Ho Yeung Lee wrote: > [... a bunch of code ...] If you want to describe a map-reduce problem, start with the data. What does a record of your input data look like? Then think about your mapper. What key-value pairs will you extract from each line of data? Then think about your reducer. For a single key and its associated values, what will you calculate? -- https://mail.python.org/mailman/listinfo/python-list
Re: [Q] ImportError by __import__() on Python >= 3.4
On Wed, Jun 8, 2016 at 10:24 PM, Michael Selik wrote: > By the way, why choose to write, import, and delete modules? I'd think > exec'ing code would be sufficient. > > In order to test my own framework for web application. It loads controller classes lazily. In other words, it loads python module only when it is required. For example: mappings = [ (r'/api/hello', 'myapp1.api.hello.Hello'),# myapp1/api/hello.py will be loaded lazily ] app = WSGIApplication(mappings) In order to test this framework, it is necessary to create and load python module file dynamically. -- regars, makoto -- https://mail.python.org/mailman/listinfo/python-list
how to solve memory
https://drive.google.com/file/d/0Bxs_ao6uuBDULVNsRjZSVjdPYlE/view?usp=sharing
M1 = {}
M2 = {}
M3 = {}
M4 = {}
M5 = {}
V6 = {}
M1['00']=0
M1['01']=2
M1['02']=1
M1['10']=1
M1['11']=1
M1['12']=1
M1['20']=1
M1['21']=1
M1['22']=2
M2['00']=0
M2['01']=1
M2['02']=1
M2['10']=1
M2['11']=1
M2['12']=1
M2['20']=1
M2['21']=1
M2['22']=1
M3['00']=2
M3['01']=2
M3['02']=2
M3['10']=0
M3['11']=2
M3['12']=1
M3['20']=0
M3['21']=1
M3['22']=2
M4['00']=1
M4['01']=2
M4['02']=1
M4['10']=2
M4['11']=2
M4['12']=2
M4['20']=0
M4['21']=1
M4['22']=2
M5['00']=0
M5['01']=1
M5['02']=1
M5['10']=0
M5['11']=2
M5['12']=1
M5['20']=0
M5['21']=1
M5['22']=1
V6['00']=1
V6['01']=1
V6['02']=2
V6['10']=1
V6['11']=2
V6['12']=1
V6['20']=1
V6['21']=2
V6['22']=2
MM = {}
MM[0] = M1
MM[1] = M2
MM[2] = M3
MM[3] = M4
MM[4] = M5
MM[5] = V6
m = 3
b = [str(i)+str(j)+str(k) for i in range(m) for j in range(m) for k in range(m)]
import itertools
deep = 3
final = []
mylist = [MM[i] for i in range(0,7-1)]
b = [str(i)+str(j)+str(k) for i in range(m) for j in range(m) for k in range(m)]
def DFS(b, deep, maxx, sourceoperators, path):
initlist = []
if deep > 0:
print("deep=", deep)
for aa,bb in itertools.combinations(sourceoperators, 2):
print(aa,bb)
if deep == maxx:
finalresult = []
op1xy = [aa[b[i][0:1]+b[i][1:2]] for i in range(len(b))]
op1yz = [aa[b[i][1:2]+b[i][2:3]] for i in range(len(b))]
op1xz = [aa[b[i][0:1]+b[i][2:3]] for i in range(len(b))]
op2xy = [bb[b[i][0:1]+b[i][1:2]] for i in range(len(b))]
op2yz = [bb[b[i][1:2]+b[i][2:3]] for i in range(len(b))]
op2xz = [bb[b[i][0:1]+b[i][2:3]] for i in range(len(b))]
if sum(op1xy) == 54:
path.append([(deep, aa, "xy")])
if sum(op1yz) == 54:
path.append([(deep, aa, "yz")])
if sum(op1xz) == 54:
path.append([(deep, aa, "xz")])
if sum(op2xy) == 54:
path.append([(deep, bb, "xy")])
if sum(op2yz) == 54:
path.append([(deep, bb, "yz")])
if sum(op2xz) == 54:
path.append([(deep, bb, "xz")])
initlist.append(op1xy)
initlist.append(op1yz)
initlist.append(op1xz)
initlist.append(op2xy)
initlist.append(op2yz)
initlist.append(op2xz)
else:
level = []
for j in range(len(b)):
op1xy = [aa[b[j][i]] for i in range(len(b[j]))]
op2xy = [bb[b[j][i]] for i in range(len(b[j]))]
if sum(op1xy) == 54:
path.append([(deep, aa, "xy")])
if sum(op2xy) == 54:
path.append([(deep, bb, "xy")])
level.append(op1xy)
level.append(op2xy)
initlist.append(op1xy)
initlist.append(op2xy)
if deep == maxx:
b = []
#print(len(list(itertools.combinations(initlist, 2
for aaa,bbb in itertools.combinations(initlist, 2):
b.append([str(i)+str(j) for i,j in zip(aaa, bbb)])
path = DFS(b, deep-1, maxx, sourceoperators, path)
else:
#print(len(list(itertools.combinations(initlist, 2
for aaa,bbb in itertools.combinations(initlist, 2):
b.append([str(i)+str(j) for i,j in zip(aaa, bbb)])
path = DFS(b, deep-1, maxx, sourceoperators, path)
return path
path = []
mresult = DFS(b, 2, 2, mylist, path)
--
https://mail.python.org/mailman/listinfo/python-list
Re: which library has map reduce and how to use it for this case
input are these six operators, output is finding full column of 27 elements add
together is 54
i got memory error when searching this,
i have difficulty in understanding map reduce and transforming my program into
map reduce problem
M1 = {}
M2 = {}
M3 = {}
M4 = {}
M5 = {}
V6 = {}
M1['00']=0
M1['01']=2
M1['02']=1
M1['10']=1
M1['11']=1
M1['12']=1
M1['20']=1
M1['21']=1
M1['22']=2
M2['00']=0
M2['01']=1
M2['02']=1
M2['10']=1
M2['11']=1
M2['12']=1
M2['20']=1
M2['21']=1
M2['22']=1
M3['00']=2
M3['01']=2
M3['02']=2
M3['10']=0
M3['11']=2
M3['12']=1
M3['20']=0
M3['21']=1
M3['22']=2
M4['00']=1
M4['01']=2
M4['02']=1
M4['10']=2
M4['11']=2
M4['12']=2
M4['20']=0
M4['21']=1
M4['22']=2
M5['00']=0
M5['01']=1
M5['02']=1
M5['10']=0
M5['11']=2
M5['12']=1
M5['20']=0
M5['21']=1
M5['22']=1
V6['00']=1
V6['01']=1
V6['02']=2
V6['10']=1
V6['11']=2
V6['12']=1
V6['20']=1
V6['21']=2
V6['22']=2
MM = {}
MM[0] = M1
MM[1] = M2
MM[2] = M3
MM[3] = M4
MM[4] = M5
MM[5] = V6
m = 3
b = [str(i)+str(j)+str(k) for i in range(m) for j in range(m) for k in range(m)]
import itertools
deep = 3
final = []
mylist = [MM[i] for i in range(0,7-1)]
b = [str(i)+str(j)+str(k) for i in range(m) for j in range(m) for k in range(m)]
def DFS(b, deep, maxx, sourceoperators, path):
initlist = []
if deep > 0:
print("deep=", deep)
for aa,bb in itertools.combinations(sourceoperators, 2):
print(aa,bb)
if deep == maxx:
finalresult = []
op1xy = [aa[b[i][0:1]+b[i][1:2]] for i in range(len(b))]
op1yz = [aa[b[i][1:2]+b[i][2:3]] for i in range(len(b))]
op1xz = [aa[b[i][0:1]+b[i][2:3]] for i in range(len(b))]
op2xy = [bb[b[i][0:1]+b[i][1:2]] for i in range(len(b))]
op2yz = [bb[b[i][1:2]+b[i][2:3]] for i in range(len(b))]
op2xz = [bb[b[i][0:1]+b[i][2:3]] for i in range(len(b))]
if sum(op1xy) == 54:
path.append([(deep, aa, "xy")])
if sum(op1yz) == 54:
path.append([(deep, aa, "yz")])
if sum(op1xz) == 54:
path.append([(deep, aa, "xz")])
if sum(op2xy) == 54:
path.append([(deep, bb, "xy")])
if sum(op2yz) == 54:
path.append([(deep, bb, "yz")])
if sum(op2xz) == 54:
path.append([(deep, bb, "xz")])
initlist.append(op1xy)
initlist.append(op1yz)
initlist.append(op1xz)
initlist.append(op2xy)
initlist.append(op2yz)
initlist.append(op2xz)
else:
level = []
for j in range(len(b)):
op1xy = [aa[b[j][i]] for i in range(len(b[j]))]
op2xy = [bb[b[j][i]] for i in range(len(b[j]))]
if sum(op1xy) == 54:
path.append([(deep, aa, "xy")])
if sum(op2xy) == 54:
path.append([(deep, bb, "xy")])
level.append(op1xy)
level.append(op2xy)
initlist.append(op1xy)
initlist.append(op2xy)
if deep == maxx:
b = []
#print(len(list(itertools.combinations(initlist, 2
for aaa,bbb in itertools.combinations(initlist, 2):
b.append([str(i)+str(j) for i,j in zip(aaa, bbb)])
path = DFS(b, deep-1, maxx, sourceoperators, path)
else:
#print(len(list(itertools.combinations(initlist, 2
for aaa,bbb in itertools.combinations(initlist, 2):
b.append([str(i)+str(j) for i,j in zip(aaa, bbb)])
path = DFS(b, deep-1, maxx, sourceoperators, path)
return path
path = []
mresult = DFS(b, 2, 2, mylist, path)
Michael Selik於 2016年6月10日星期五 UTC+8上午6時45分14秒寫道：
> I like using Yelp's mrjob module (https://github.com/Yelp/mrjob) to run
> Python on Hadoop.
>
> On Thu, Jun 9, 2016 at 2:56 AM Ho Yeung Lee
> wrote:
>
> > [... a bunch of code ...]
>
>
> If you want to describe a map-reduce problem, start with the data. What
> does a record of your input data look like?
>
> Then think about your mapper. What key-value pairs will you extract from
> each line of data?
>
> Then think about your reducer. For a single key and its associated values,
> what will you calculate?
--
https://mail.python.org/mailman/listinfo/python-list
Re: how to solve memory
On 06/09/2016 06:58 PM, meInvent bbird wrote: > Do you have a question for the list? If so, please state what it is, and describe what you are doing and what isn't working. If you can boil it down to a dozen lines of run-able, self-contained code that illustrates the problem, that is helpful too. -- https://mail.python.org/mailman/listinfo/python-list
Re: how to solve memory
On Friday, June 10, 2016 at 9:13:13 AM UTC+8, Michael Torrie wrote: > On 06/09/2016 06:58 PM, meInvent bbird wrote: > > > > Do you have a question for the list? If so, please state what it is, and > describe what you are doing and what isn't working. If you can boil it > down to a dozen lines of run-able, self-contained code that illustrates > the problem, that is helpful too. there are six operator, and a logic table initial in b variable aa[b[j][i]] [aa[b[i][0:1]+b[i][2:3] are just like vlookup to find output of each operator acting on first column and second column, second column and third column , first column and third column and searching a output columns which is result sum is 27*2 and record the path if succeed, it record the path and output any path which has result is 27*2 described before op1(op2(op3(op1(op2(),),op1(op2(),))), op1(op2(),)) there are two cases, first cases b are logic table later case are for six operators acting on the result column from previous result before recursive call -- https://mail.python.org/mailman/listinfo/python-list
Re: I'm wrong or Will we fix the ducks limp?
Marko Rauhamaa writes: > Paul Rudin wrote: >> Talk of pointers is potentially confusing, because it carries baggage >> from other languages which doesn't necessary map precisely onto the >> python execution model. > > Unfortunately, virtually every word is overloaded and full of > preconceived notions. Hence: "pegs", "leashes", "puppies". > > The main thing is to keep those three concepts apart from each other. > Two notions will not suffice. Does a new leash appear when a puppy is tied to a peg? Apparently. Is it possible to tie two puppies to the same peg? Apparently not. Why not? Is the leash left dangling in the neck of a puppy if another puppy is tied to its peg? What if the puppy is tied again to the same peg, is there then the new leash from its neck to the peg, and the old leash left dangling? Is it possible to leave the leash tied to the peg but untie the puppy? Apparently not. It's also not possible to look at the puppy and follow all the leashes to find all the pegs where the puppy is tied. The real third thing is not a thing but a relationship: being tied to. -- https://mail.python.org/mailman/listinfo/python-list
