Re: I thought I understood how import worked...
On 2012-08-08 06:14, Ben Finney wrote:
Cameron Simpson writes:
All of you are saying "two names for the same module", and variations
thereof. And that is why the doco confuses.
I would expect less confusion if the above example were described as
_two_ modules, with the same source code.
That's not true though, is it? It's the same module object with two
different references, I thought.
They are not the same. Proof:
$ mkdir test
$ cd test
$ touch __init__.py
$ touch m.py
$ cd ..
$ python
Python 2.7.3 (default, Apr 20 2012, 22:39:59)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.append('test')
>>> import m
>>> from test import m
>>> import m
>>> from test import m as m2
>>> m is m2
False
>>> m.a = 3
>>> m2.a
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'module' object has no attribute 'a'
So it is still true that top level code gets executed only once, when
the module is first imported. The trick is that a module is not a file.
It is a module object that is created from a file, with a name. If you
change the name, then you create ("import") a new module.
You can also use the reload() function to execute module level code
again, but it won't create a new module object. It will just update the
contents of the very same module object:
What is more interesting is how the reload() function works:
Python 2.7.3 (default, Apr 20 2012, 22:39:59)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import test.m
>>> a = test.m
>>> import os
>>> test.m is a
True
>>> os.system("echo \"import sys\" >> test/m.py")
0
>>> reload(test.m) # Updates the module object
>>> test.m is a # They are still the same
True
>>> a.sys # So a.sys is a exist
>>>
--
http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
Cameron Simpson writes: > All of you are saying "two names for the same module", and variations > thereof. And that is why the doco confuses. > > I would expect less confusion if the above example were described as > _two_ modules, with the same source code. That's not true though, is it? It's the same module object with two different references, I thought. Also, even if what you say were true, “source code” implies the module was loaded from source code, when Python allows loading modules with no source code available. So that implication just seems to be inviting different confusion. -- \ “I'm not a bad guy! I work hard, and I love my kids. So why | `\ should I spend half my Sunday hearing about how I'm going to | _o__)Hell?” —Homer Simpson | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a good introduction to object oriented programming with Python
On Aug 8, 12:14 pm, Steven D'Aprano wrote: > You claim that named Patterns simplify and clarify communication. If you > have to look the terms up, they aren't simplifying and clarifying > communication, they are obfuscating it. By that argument, an encyclopaedia is useless because if you have to look up the meaning of something by its name... Names are identifiers for exactly that reason, to make look up easier. Names aren't meant to encode every aspect of what they represent. Or why distinguish between quick sort & merge sort? Let's just talk about "sort", that's simpler. > The time I save in writing "Foo Visitor" is lost a dozen times over for > every one of my readers who has to look it up to find out what I mean. What would you call it that would remove the need for _anyone_ to look up/ask you what it meant? > And if somebody else uses "Foo Visitor" to mean something different to > what I mean, we now have a communication mismatch. Do we just not use names at all? How do you communicate what you're doing in this instance? > There is a point of diminishing returns in terminology, where finer > distinctions lead to less clarity rather than more, and in my opinion > that point was already passed when Go4 wrote their book, and it's just > got worse since. Can you please point me to a standardised way for talking about abstract patterns of behaviour across languages? -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a good introduction to object oriented programming with Python
On Wed, Aug 8, 2012 at 12:14 PM, Steven D'Aprano
wrote:
> NoneType raises an error if you try to create a second instance. bool
> just returns one of the two singletons (doubletons?) again.
>
> py> type(None)()
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: cannot create 'NoneType' instances
> py> type(False)() is False
> True
This is necessitated by the use of bool(x) as a means of boolifying
("casting to bool", if you like) x. I wouldn't want that to change,
and since type(False) is bool, what you see is bound to occur.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a good introduction to object oriented programming with Python
On Tue, 07 Aug 2012 17:07:59 -0700, alex23 wrote:
>> I'm pretty sure that people could talk about good coding design before
>> the Gof4. As you say, they didn't invent the patterns. So people
>> obviously wrote code, and talked about algorithms, without the Gof4
>> terminology.
>
> So what did people call Singletons before the pattern was named? If I
> was talking about "global uniques" and you were talking about "single
> instantiation", would we even recognise we were discussing the same
> thing?
But are we? If we're comparing code written in two languages, we don't
even know if "global" means the same -- it could be global to a single
module, or global to the entire program.
Singletons encompass many different behaviours under a single name. If I
delete the single instance, and recreate it, will it necessarily have the
same state? Calling it a singleton doesn't answer that question. We still
have to agree on what behaviour this particular singleton has.
NoneType raises an error if you try to create a second instance. bool
just returns one of the two singletons (doubletons?) again.
py> type(None)()
Traceback (most recent call last):
File "", line 1, in
TypeError: cannot create 'NoneType' instances
py> type(False)() is False
True
And modules are singletons, even though there is no upper limit to the
number of distinct module objects you can get. So if I tell you that X is
a singleton, you don't even know something as fundamental as whether or
not X is the only instance of its type.
> The Go4 book was as much about the approach of naming and documenting
> patterns as describing the patterns they saw. It was just an attempt at
> formally approaching what we were previously doing anyway.
>
>> I don't think that "Memento Pattern" is any more clear than "save and
>> restore".
>
> And I don't think that everyone making up their own terminology helps
> with the _communicativeness_ of code.
Are you saying that Go4 shouldn't have made up their own terminology?
"Save and restore" is plain English which predates "Memento Pattern". I
was writing code in the 1980s like:
save := something;
do_stuff_to(something);
something := save; {restore old value}
which is the Memento pattern in non-OOP Pascal.
>> And the ever-finer distinctions between variations on patterns. Without
>> looking them up, what are the difference between Default Visitor,
>> Extrinsic Visitor, Acyclic Visitor, Hierarchical Visitor, Null Object
>> And Visitor, and regular old Visitor patterns? -- and no, I did not
>> make any of them up.
>
> Why wouldn't I look them up?
You claim that named Patterns simplify and clarify communication. If you
have to look the terms up, they aren't simplifying and clarifying
communication, they are obfuscating it.
The time I save in writing "Foo Visitor" is lost a dozen times over for
every one of my readers who has to look it up to find out what I mean.
And if somebody else uses "Foo Visitor" to mean something different to
what I mean, we now have a communication mismatch. The finer the
distinction between Foo and Bar Visitor, the more likely that people will
misunderstand or fail to see the distinction, and the less useful the
terminology gets.
There is a point of diminishing returns in terminology, where finer
distinctions lead to less clarity rather than more, and in my opinion
that point was already passed when Go4 wrote their book, and it's just
got worse since.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: looking for a neat solution to a nested loop problem
Nobody於 2012年8月7日星期二UTC+8下午11時32分55秒寫道： > On Mon, 06 Aug 2012 21:02:33 -0700, Larry Hudson wrote: > > > > >> for i in range(N,N+100): > > >> for j in range(M,M+100): > > >> do_something(i % 100 ,j % 100) > > >> > > >> Emile > > > > > > How about... > > > > > > for i in range(100): > > > for j in range(100): > > > do_something((i + N) % 100, (j + M) % 100) > > > > Both of these approaches move the modifications to the sequence into the > > body of the loop. It may be preferable to iterate over the desired > > sequence directly. E.g. > > > > for i in ((N + ii) % 100 for ii in xrange(100)): > > for j in ((M + jj) % 100 for jj in xrange(100)): > > do_something(i, j) Nobody於 2012年8月7日星期二UTC+8下午11時32分55秒寫道： > On Mon, 06 Aug 2012 21:02:33 -0700, Larry Hudson wrote: > > > > >> for i in range(N,N+100): > > >> for j in range(M,M+100): > > >> do_something(i % 100 ,j % 100) > > >> > > >> Emile > > > > > > How about... > > > > > > for i in range(100): > > > for j in range(100): > > > do_something((i + N) % 100, (j + M) % 100) > > > > Both of these approaches move the modifications to the sequence into the > > body of the loop. It may be preferable to iterate over the desired > > sequence directly. E.g. > > > > for i in ((N + ii) % 100 for ii in xrange(100)): > > for j in ((M + jj) % 100 for jj in xrange(100)): > > do_something(i, j) This is a good example to be tuned into some example such that this kind of loops by iterators of parameters in python wich do not use any division at all. But I am getting lazy recently for non-critical parts. -- http://mail.python.org/mailman/listinfo/python-list
Re: dbf.py API question
On Aug 2, 2012, at 10:55 AM, Ethan Furman wrote: > SQLite has a neat feature where if you give it a the file-name of ':memory:' > the resulting table is in memory and not on disk. I thought it was a cool > feature, but expanded it slightly: any name surrounded by colons results in > an in-memory table. > > I'm looking at the same type of situation with indices, but now I'm wondering > if the :name: method is not pythonic and I should use a flag (in_memory=True) > when memory storage instead of disk storage is desired. When converting from paradigms in other languages, I've often been tempted to follow the accepted pattern for that language, and I've almost always regretted it. When in doubt, make it as Pythonic as possible. -- Ed Leafe -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a good introduction to object oriented programming with Python
On Aug 8, 5:02 am, Steven D'Aprano wrote: > I haven't read the Gang of Four book itself, but I've spent plenty of > time being perplexed by over-engineered, jargon-filled code, articles, > posts and discussions by people who use Design Patterns as an end to > themselves rather than a means to an end. (Singleton is notoriously bad > in that way.) The Go4 book isn't perfect, and I don't agree with all of their patterns. But they themselves made it very clear that _you're not supposed to_. It's meant to provide a mechanism for discussion and debate. It's _just another tool for development_; it's not a silver bullet, and anyone who claims otherwise is just a desperate marketing shill. _Not_ using a pattern should be as much a part of any conversation as using it. (But then, I love the word "synergy" too. Just because something has been driven into the ground through marketing misuse or overeager misapplication doesn't make the basic concept itself worthless.) > I think that as languages get more powerful, "Design Patterns" just > become language features, and people stop talking about them. Nobody > talks about Function Pattern, but everyone uses it. In Python, we don't > talk about the Iterator Pattern. We just use iterators. I'm not making the distinction between "iterator pattern" and "iterators". Talking about one is talking about the other. That's _all_ I see design patterns as: naming and defining commonly re-used aspects of functionality. Not invention, recognition. > I'm pretty sure that people could talk about good coding design before > the Gof4. As you say, they didn't invent the patterns. So people > obviously wrote code, and talked about algorithms, without the Gof4 > terminology. So what did people call Singletons before the pattern was named? If I was talking about "global uniques" and you were talking about "single instantiation", would we even recognise we were discussing the same thing? The Go4 book was as much about the approach of naming and documenting patterns as describing the patterns they saw. It was just an attempt at formally approaching what we were previously doing anyway. > I don't think that "Memento Pattern" is any more clear than "save and > restore". And I don't think that everyone making up their own terminology helps with the _communicativeness_ of code. > And the ever-finer distinctions between variations on patterns. Without > looking them up, what are the difference between Default Visitor, > Extrinsic Visitor, Acyclic Visitor, Hierarchical Visitor, Null Object And > Visitor, and regular old Visitor patterns? -- and no, I did not make any > of them up. Why wouldn't I look them up? The point is that they represent experience with solving certain problems. _Someone_ felt the distinction was necessary; by their documenting it I can read it and decide whether the distinction is relevant to me. Maybe they considered edge cases I didn't. But telling me _not_ to look at the definition of a design pattern and just "intuit" it's meaning is, again, missing the point of having a means of communicating experience with specific problem domains. -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
In article , Cameron Simpson wrote: > This, I think, is a core issue in this misunderstanding. (I got bitten > by this too, maybe a year ago. My error, and I'm glad to have improved > my understanding.) > > All of you are saying "two names for the same module", and variations > thereof. And that is why the doco confuses. > > I would expect less confusion if the above example were described as > _two_ modules, with the same source code. +1 -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
On 07Aug2012 13:52, Steven D'Aprano wrote: | On Tue, 07 Aug 2012 09:18:26 -0400, Roy Smith wrote: | > I thought modules could not get imported twice. The first time they get | > imported, they're cached, and the second import just gets you a | > reference to the original. Playing around, however, I see that it's | > possible to import a module twice if you refer to it by different names. | | Yes. You've found a Python gotcha. [...] | > $ cat try.py | > import broken | > import foo.broken | | Which are two names for the same module. [...] This, I think, is a core issue in this misunderstanding. (I got bitten by this too, maybe a year ago. My error, and I'm glad to have improved my understanding.) All of you are saying "two names for the same module", and variations thereof. And that is why the doco confuses. I would expect less confusion if the above example were described as _two_ modules, with the same source code. Make it clear that these are _two_ modules (because they have two names), who merely happen to have been obtained from the same "physical" filesystem object due to path search effects i.e. change the doco wording to describe a module as the in-memory result of reading a "file" found from an import name. So I think I'm arguing for a small change in terminology in the doco with no change in Python semantics. Is a module a set of files on the disc, or an in-memory Python notion with a name? I would argue for the latter. With such a change, the "a module can't be imported twice" would then be true (barring hacking around in sys.modules between imports). Cheers, -- Cameron Simpson As you can see, unraveling even a small part of 'sendmail' can introduce more complexity than answers.- Brian Costales, _sendmail_ -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a good introduction to object oriented programming with Python
On 8/7/2012 3:02 PM, Steven D'Aprano wrote: On Sun, 05 Aug 2012 19:44:31 -0700, alex23 wrote: I think you've entirely missed the point of Design Patterns. Perhaps I have. Or perhaps I'm just (over-)reacting to the abuse of Patterns: http://c2.com/cgi/wiki?DesignPatternsConsideredHarmful or that they are a crutch for underpowered languages: I still remember reading an article something like "Implementing the Composite Pattern in C++". The example for the discussion was Pictures that could contain sub-Pictures as well as Graphic elements. I eventually realized that a) this is trivial in Python, b) the article was really about how to lie to a C++ compiler, so it would accept recursive heterogenous structures, and c) I preferred Python. http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures I think that as languages get more powerful, "Design Patterns" just become language features, and people stop talking about them. Nobody talks about Function Pattern, but everyone uses it. In Python, we don't talk about the Iterator Pattern. We just use iterators. In pre 2.2 Python, there was talk about the pattern (but not with Capitals) and how to lie to the interpreter with a fake __getitem__ method. I'm pretty sure that people could talk about good coding design before the Gof4. As you say, they didn't invent the patterns. So people obviously wrote code, and talked about algorithms, without the Gof4 terminology. 'Divide and conquer' is an old, descriptive name for an algorithm action pattern. It is only incidentally about static structures. 'Dynamic programming' is a rather opaque name for a) an action patter for using the optimality principle* (when applicable) and b) not disposing of data one still needs. * the best path from A to B that passes through C is the best path from A to C plus the best path from C to B. Lisp is based on a simple data pattern (or is it a principle): collection (of dicrete items) = one item + remainder, used to both construct and deconstruct. Python iterator embody the the same principle. next(iterator) = iterator: return one item and mutate yourself to represent the rest -- or raise StopIteration. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a good introduction to object oriented programming with Python
On Wed, Aug 8, 2012 at 3:00 AM, lipska the kat wrote: > I'm still undecided over the whole 'User' thing actually, I don't think I > can see a time when I will have a User Class in one of my systems but as I > don't want to get 'dogmatic' about this I remain open to any ideas that > might include such a Class. > > Person however is an entirely different matter and will never appear in my > systems in any way shape or form ...this is not dogma, it's a fact. This makes little sense to my mind. If you can have a "class User:", why can you not have a "class Person:" ? Now, that said, I can't remember the last time I actually had a class called "Person" in anything other than a demo. But that's merely because of terminology; I've had classes representing human beings, but named according to what part these people play in the system (Customer, Employee (haven't done that one, actually, but there's no reason not to), User, Etcetera, Etcetera, Etcetera... is an Etceterer someone who practices Etcetery?), and these classes are as well-defined as any others. Perhaps it would help to think about these things not as turning a person into an entity, but as "retaining the data related to a Person". The Person class details what data you store about a person, a Person instance stores that data about one particular person. This works for other things; a QueueEntry isn't actually standing in queue, but it holds the data you store about the thing that is. Or maybe that doesn't help, in which case just ignore it. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
[ANNOUNCE] pypiserver 0.6.1 - minimal private pypi server
Hi, I've just uploaded pypiserver 0.6.1 to the python package index. pypiserver is a minimal PyPI compatible server. It can be used to serve a set of packages and eggs to easy_install or pip. pypiserver is easy to install (i.e. just easy_install pypiserver). It doesn't have any external dependencies. http://pypi.python.org/pypi/pypiserver/ should contain enough information to easily get you started running your own PyPI server in a few minutes. The code is available on github: https://github.com/schmir/pypiserver Changes in version 0.6.1 - make 'python setup.py register' work - added init scripts to start pypiserver on ubuntu/opensuse -- Cheers Ralf -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] String to binary conversion
Steven D'Aprano於 2012年8月7日星期二UTC+8上午10時01分05秒寫道：
> On Mon, 06 Aug 2012 22:46:38 +0200, Mok-Kong Shen wrote:
>
>
>
> > If I have a string "abcd" then, with 8-bit encoding of each character,
>
> > there is a corresponding 32-bit binary integer. How could I best obtain
>
> > that integer and from that integer backwards again obtain the original
>
> > string? Thanks in advance.
>
>
>
> First you have to know the encoding, as that will define the integers you
>
> get. There are many 8-bit encodings, but of course they can't all encode
>
> arbitrary 4-character strings. Since there are tens of thousands of
>
> different characters, and an 8-bit encoding can only code for 256 of
>
> them, there are many strings that an encoding cannot handle.
>
>
>
> For those, you need multi-byte encodings like UTF-8, UTF-16, etc.
>
>
>
> Sticking to one-byte encodings: since most of them are compatible with
>
> ASCII, examples with "abcd" aren't very interesting:
>
>
>
> py> 'abcd'.encode('latin1')
>
> b'abcd'
>
>
>
> Even though the bytes object b'abcd' is printed as if it were a string,
>
> it is actually treated as an array of one-byte ints:
>
>
>
> py> b'abcd'[0]
>
> 97
>
>
>
> Here's a more interesting example, using Python 3: it uses at least one
>
> character (the Greek letter π) which cannot be encoded in Latin1, and two
>
> which cannot be encoded in ASCII:
>
>
>
> py> "aπ©d".encode('iso-8859-7')
>
> b'a\xf0\xa9d'
>
>
>
> Most encodings will round-trip successfully:
>
>
>
> py> text = 'aπ©Z!'
>
> py> data = text.encode('iso-8859-7')
>
> py> data.decode('iso-8859-7') == text
>
> True
>
>
>
>
>
> (although the ability to round-trip is a property of the encoding itself,
>
> not of the encoding system).
>
>
>
> Naturally if you encode with one encoding, and then decode with another,
>
> you are likely to get different strings:
>
>
>
> py> text = 'aπ©Z!'
>
> py> data = text.encode('iso-8859-7')
>
> py> data.decode('latin1')
>
> 'að©Z!'
>
> py> data.decode('iso-8859-14')
>
> 'aŵ©Z!'
>
>
>
>
>
> Both the encode and decode methods take an optional argument, errors,
>
> which specify the error handling scheme. The default is errors='strict',
>
> which raises an exception. Others include 'ignore' and 'replace'.
>
>
>
> py> 'aŵðπ©Z!'.encode('ascii', 'ignore')
>
> b'aZ!'
>
> py> 'aŵðπ©Z!'.encode('ascii', 'replace')
>
> b'aZ!'
>
>
>
>
>
>
>
> --
>
> Steven
Steven D'Aprano於 2012年8月7日星期二UTC+8上午10時01分05秒寫道：
> On Mon, 06 Aug 2012 22:46:38 +0200, Mok-Kong Shen wrote:
>
>
>
> > If I have a string "abcd" then, with 8-bit encoding of each character,
>
> > there is a corresponding 32-bit binary integer. How could I best obtain
>
> > that integer and from that integer backwards again obtain the original
>
> > string? Thanks in advance.
>
>
>
> First you have to know the encoding, as that will define the integers you
>
> get. There are many 8-bit encodings, but of course they can't all encode
>
> arbitrary 4-character strings. Since there are tens of thousands of
>
> different characters, and an 8-bit encoding can only code for 256 of
>
> them, there are many strings that an encoding cannot handle.
>
>
>
> For those, you need multi-byte encodings like UTF-8, UTF-16, etc.
>
>
>
> Sticking to one-byte encodings: since most of them are compatible with
>
> ASCII, examples with "abcd" aren't very interesting:
>
>
>
> py> 'abcd'.encode('latin1')
>
> b'abcd'
>
>
>
> Even though the bytes object b'abcd' is printed as if it were a string,
>
> it is actually treated as an array of one-byte ints:
>
>
>
> py> b'abcd'[0]
>
> 97
>
>
>
> Here's a more interesting example, using Python 3: it uses at least one
>
> character (the Greek letter π) which cannot be encoded in Latin1, and two
>
> which cannot be encoded in ASCII:
>
>
>
> py> "aπ©d".encode('iso-8859-7')
>
> b'a\xf0\xa9d'
>
>
>
> Most encodings will round-trip successfully:
>
>
>
> py> text = 'aπ©Z!'
>
> py> data = text.encode('iso-8859-7')
>
> py> data.decode('iso-8859-7') == text
>
> True
>
>
>
>
>
> (although the ability to round-trip is a property of the encoding itself,
>
> not of the encoding system).
>
>
>
> Naturally if you encode with one encoding, and then decode with another,
>
> you are likely to get different strings:
>
>
>
> py> text = 'aπ©Z!'
>
> py> data = text.encode('iso-8859-7')
>
> py> data.decode('latin1')
>
> 'að©Z!'
>
> py> data.decode('iso-8859-14')
>
> 'aŵ©Z!'
>
>
>
>
>
> Both the encode and decode methods take an optional argument, errors,
>
> which specify the error handling scheme. The default is errors='strict',
>
> which raises an exception. Others include 'ignore' and 'replace'.
>
>
>
> py> 'aŵðπ©Z!'.encode('ascii', 'ignore')
>
> b'aZ!'
>
> py> 'aŵðπ©Z!'.encode('ascii', 'replace')
>
> b'aZ!'
>
>
>
>
>
>
>
> --
>
> Steven
I think UTF-8 CODEC or UTF-16 is nece
Re: Looking for a good introduction to object oriented programming with Python
On Sun, 05 Aug 2012 19:44:31 -0700, alex23 wrote: > I think you've entirely missed the point of Design Patterns. Perhaps I have. Or perhaps I'm just (over-)reacting to the abuse of Patterns: http://c2.com/cgi/wiki?DesignPatternsConsideredHarmful or maybe I'm just not convinced that Design Patterns as described by the Go4 are as important and revolutionary as so many people seem to believe: http://perl.plover.com/yak/design/ or that they are a crutch for underpowered languages: http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures I haven't read the Gang of Four book itself, but I've spent plenty of time being perplexed by over-engineered, jargon-filled code, articles, posts and discussions by people who use Design Patterns as an end to themselves rather than a means to an end. (Singleton is notoriously bad in that way.) On the other hand, as I think I've stated before, the design patterns themselves aren't *necessarily* bad. They're just problem solving techniques and common idioms. I think that as languages get more powerful, "Design Patterns" just become language features, and people stop talking about them. Nobody talks about Function Pattern, but everyone uses it. In Python, we don't talk about the Iterator Pattern. We just use iterators. > No one claims that the Go4 DP book introduced Builders, Singletons, > Facades. The point was to identify _and name_ such patterns, so > programmers could actually talk about repeated behaviour. I'm pretty sure that people could talk about good coding design before the Gof4. As you say, they didn't invent the patterns. So people obviously wrote code, and talked about algorithms, without the Gof4 terminology. I don't think that "Memento Pattern" is any more clear than "save and restore". When you have a few standard patterns, everyone can know what they are. When you start getting into multiple dozens, it's not so clear to me that they are all *standard* any more. http://c2.com/cgi/wiki?CategoryPattern And the ever-finer distinctions between variations on patterns. Without looking them up, what are the difference between Default Visitor, Extrinsic Visitor, Acyclic Visitor, Hierarchical Visitor, Null Object And Visitor, and regular old Visitor patterns? -- and no, I did not make any of them up. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Deciding inheritance at instantiation?
Interesting stuff. Thanks. On 08/06/2012 07:53 PM, alex23 wrote: On Aug 4, 6:48 am, Tobiah wrote: I have a bunch of classes from another library (the html helpers from web2py). There are certain methods that I'd like to add to every one of them. So I'd like to put those methods in a class, and pass the parent at the time of instantiation. Web2py has a FORM class for instance. I'd like to go: my_element = html_factory(FORM) Then my_element would be an instance of my class, and also a child of FORM. I've lately begun to prefer composition over inheritance for situations like this: class MyElementFormAdapter(object): def __init__(self, form): self.form = form def render_form(self): self.form.render() my_element = MyElementFormAdapter(FORM) my_element.render_form() my_element.form.method_on_form() Advantages include being more simple and obvious than multiple inheritance, and avoiding namespace clashes: class A(object): def foo(self): print 'a' class B(object): def foo(self): print 'b' class InheritFromAB(A, B): pass class AdaptAB(object): def __init__(self, a, b): self.a = a self.b = b >>> inherit = InheritFromAB() >>> inherit.foo() a >>> adapt = AdaptAB(A(), B()) >>> adapt.a.foo() a >>> adapt.b.foo() b -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
On Tue, 07 Aug 2012 08:25:43 -0700, Roy Smith wrote: > On Tuesday, August 7, 2012 9:52:59 AM UTC-4, Steven D'Aprano wrote: > >> In general, you should avoid non-idempotent code. You should doubly >> avoid it during imports, and triply avoid it on days ending with Y. You seem to have accidentally deleted my smiley. > I don't understand your aversion to non-idempotent code as a general > rule. Most code is non-idempotent. That doesn't necessarily make it a good thing. Most code is also buggy. > Surely you're not saying we should never write: > foo += 1 > > or > my_list.pop() > > ??? Of course not. I'm not going so far as to say that we should always, without exception, write purely functional code. I like my list.append as much as anyone :) But at the level of larger code units, functions and modules, it is a useful property to have where possible. A function is free to increment an integer, or pop items from a list, as much as it likes -- so long as they are *local* to the function, and get reset to their initial state each time the function is called with the same arguments. I realise that many problems are most easily satisfied by non-idempotent tactics. "Customer orders widget" is not naturally idempotent, since if the customer does it twice, they get two widgets, not one. But such behaviour should be limited to the parts of your code which must be non- idempotent. In short, non-idempotent code is hard to get right, hard to test, and hard to debug, so we should use as little of it as possible. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Unexpected behavior using contextmanager on a class method
On Tue, 07 Aug 2012 08:30:15 -0700, Thomas Draper wrote: > I want to use with..as in a "reversible circuit generator". However, it > seems that @contextmanager changes the expected nature of the class. I > tried to distill the problem down to a simple example. Nothing to do with contextmanager. That's a red-herring. Your error is here: class SymList: def __init__(self, L=[]): self.L = L The default value for L is only set *once*, when the function is defined, NOT every time the function is called. Later on, in the SymAdd method you modify that list in place. So naturally later instances see the changes, because you have changed the default list. You can see this "early binding" of the default value in action with this simple example: import time def test(x=time.ctime()): # Default values are set *once*, not each time. print(x) test() => always prints Wed Aug 8 03:40:32 2012 (or whatever time the function is defined). In this example, the default value is a string, and cannot be changed; but in your code it is a list, and can be modified in place. Either way, the result is the same: you get the same object used as the default, each and every time. In your case, you can fix this problem and get the effect of "late binding" like this: class SymList: def __init__(self, L=None): if L is None: L = [] self.L = L Now each time the method body runs, you get a different empty list. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Procedure to request adding a module to the standard library - or initiating a vote on it
On 8/7/2012 6:13 AM, Helmut Jarausch wrote: I'd like to request adding the module http://pypi.python.org/pypi/regex to Python's standard library in the (near) future As near as I can tell, the author is lukewarm about the prospect. To respond the general question: The author of a module should be warm to hot about the idea and must be willing to move development into the stdlib source tree and conform to Python's release schedule, which may be too slow for actively developed modules. (If the module wraps a well-known and maintained external C library, the wrapper must go into the source tree. Then the docs says that the stdlib module wraps something we are not responsible for.) There should be community support for the module as one of the best of its kind. Someone has to write a PEP. There must be developer support to review the code, api, and documentation. Author must allow changes. (The new ipaddress module has had changes to all three, including considerable doc expansion. Some were to make it accessible to beginners rather than only ip experts, others to make it conform to current 3.x stdlib standards and best practices. For instance, 2.x style list returns were changed to 3.x style iterator returns. ) There must be commitment for the author or substitute for maintenance. For a long term project I also need some "guarantee" that this functionality will exist in future. That is the point of the last requirement. So, is there a (formal) procedure for such a request or for initiating some sort of vote on it? 'voting' is fuzzy. Community support. Some support from developers. Best no strong opposition from a senior core developer, or at least more that one. Final decision is always by GvR, but he often delegates decisions to other developers, especially in an area of his non-expertise. I know there is a "Benevolent Dictator" for Python. Should I try to contact him personally? No. If there is author and community support, the next step is a PEP or discussion on python-ideas list (which Guido reads even if he does not write much). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
On 07/08/2012 14:18, Roy Smith wrote:
I've been tracking down some weird import problems we've been having with
django. Our settings.py file is getting imported twice. It has some
non-idempotent code in it, and we blow up on the second import.
I thought modules could not get imported twice. The first time they get
imported, they're cached, and the second import just gets you a reference to the
original. Playing around, however, I see that it's possible to import a module
twice if you refer to it by different names. Here's a small-ish test case which
demonstrates what I'm talking about (python 2.6.5):
In directory /home/roy/play/import/foo, I've got:
__init__.py (empty file)
try.py
broken.py
$ cat broken.py
print __file__
$ cat try.py
import broken
import foo.broken
import sys
for m in sys.modules.items():
if m[0].endswith('broken'):
print m
And when I run try.py (with foo as the current directory):
$ PYTHONPATH=/home/roy/play/import python try.py
/home/roy/play/import/foo/broken.pyc
/home/roy/play/import/foo/broken.pyc
('broken', )
('foo.broken', )
So, it appears that you *can* import a module twice, if you refer to it by
different names! This is surprising. It means that having non-idempotent code
which is executed at import time is a Bad Thing.
It also means that you could have multiple copies of a module's global
namespace, depending on how your users imported the module. Which is kind of
mind-blowing.
Maybe not directly applicable to what you're saying, but Brett Cannon
ought to know something about the import mechanism. I believe he's been
working on it on and off for several years. See
http://docs.python.org/dev/whatsnew/3.3.html for a starter on the gory
details.
--
Cheers.
Mark Lawrence.
--
http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
On 8/7/2012 11:32 AM, Roy Smith wrote: On Tuesday, August 7, 2012 9:55:16 AM UTC-4, Ben Finney wrote: The tutorial is misleading on this. It it says plainly: A module can contain executable statements as well as function definitions. […] They are executed only the *first* time the module is imported somewhere. The last sentence should be more like "They are executed only the *first* time the module is imported anywhere with a particular name. (One should avoid importing a module under different names.) http://docs.python.org/tutorial/modules.html> [1] In fact function definitions are also ‘statements’ that are ‘executed’; the execution of a module-level function enters the function name in the module’s global symbol table. I think what it's supposed to say is "... the execution of a module-level def statement ..." right Care to file a documentation bug http://bugs.python.org/> describing this? Sure, once I understand how it's really supposed to work :-) You don't need a final solution to file. Anyway, I think the change above might be enough. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Q on regex
On 07/08/2012 11:52, Helmut Jarausch wrote:> Hi Matthew,
>
> how to fix the code below to match 'Hellmuth' instead of ' Hellmut' ?
>
> A negative look behind in front of the pattern doesn't help since it
> counts
> as an error. One would need a means to mix a required match with a
> fuzzy match.
>
>
> #!/usr/bin/python3
> import regex
>
> Author= regex.compile(r'(?:Helmut){e<=2}')
>
> R=Author.search('Jarausch Hellmuth')
> if R :
> print("matching string : |{0}|".format(R.group()))
> # matches ' Hellmut'
> else :
> print("nothing matched")
>
There are two ways you could do it.
One way is to put word boundaries outside the fuzzy match:
Author = regex.compile(r'\b(?:Helmut){e<=2}\b')
The other way is to use the 'ENHANCEMATCH' flag (or '(?e)' in the
pattern), which tells it to 'enhance' the match by reducing the number
of errors:
Author = regex.compile(r'(?e)(?:Helmut){e<=2}')
>
> Many thanks for a hint,
> Helmut.
>
> P.S. I've tried to initiate a discussion on adding your module to the
> current standard library on C.L.P.
>
The problem with adding it to the standard library is that any releases
would be tied to Python's releases and I would have much less leeway in
making changes. There are a number of other modules which remain
outside the standard library for just that reason.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a good introduction to object oriented programming with Python
On 07/08/12 16:04, rusi wrote: On Aug 7, 7:34 pm, lipska the kat wrote: Never thought so for a moment, good to know you can be reasonable as well as misguided ;-) Well Lipska I must say that I find something resonant about the 'no- person' thing, though I am not sure what. You also said something about 'user' being more acceptable. From a different (opposite?) angle Dijkstra seems to be saying the same thing, here: http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD618.html Wonder what you make of it? This text is often quoted in discussions I have had on this subject on Usenet and other forums. Professor Dijkstra is far more eloquent that I could ever hope to be. I don't profess to be an academic nor do I have the rhetorical ability of some of the people in this group, having said that I think the professor may be equally as indignant about the word elbowing it's way into his native language as he is about the way the word is used in the computing industry but here is my rationale for thinking that there is a case for a class called User. A 'User' of a computer system can be another computer system, equally a Person can be a user of a computer system. Denying the use of the concept User may inhibit certain thought processes. At the very least 'User' can be used as a place holder indicating that we are aware that we are dealing with something that will eventually need to communicate outside of it's boundaries. Abstracting away an entire 'class' of concepts into a single 4 letter word can be wonderfully liberating. When you tell a group of struggling software developers to ignore external influences but be aware that there is this thing called 'User' that will eventually have to communicate with the thing we are inventing they breath a huge sigh of relief and start to focus on what is important, namely the business logic of the entity that is employing them. Once a basic design has been thrashed out we can start thinking about how external systems (and 'People') interface with the representation of the business we have invented. We then iterate and re-iterate as external influences invariably affect our design, however the core design remains and acts as an anchor to our thinking. In the past, when we have got confused and frustrated with these external influences we have gone back to our original design to ground ourselves again. Having said all this it has never been my experience that we actually end up with a User Class in any design I have been involved in. Eventually we just find ourselves in a place where the 'User' has transmogrified into a collection of facades and interfaces that present a view of the system to the outside world. I'm still undecided over the whole 'User' thing actually, I don't think I can see a time when I will have a User Class in one of my systems but as I don't want to get 'dogmatic' about this I remain open to any ideas that might include such a Class. Person however is an entirely different matter and will never appear in my systems in any way shape or form ...this is not dogma, it's a fact. lipska -- Lipska the Kat: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
On 8/7/2012 9:28 AM, Ramchandra Apte wrote: I don't think the modules are actually imported twice. This is incorrect as Roy's original unposted example showed. Modify one of the two copies and it will be more obvious. PS. I agree with Mark about top posting. I often just glance as such postings rather that go look to find out the context. However, this one is wrong on its own ;-). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
On Aug 7, 2012 8:41 AM, "Roy Smith" wrote: > > On Tuesday, August 7, 2012 9:55:16 AM UTC-4, Ben Finney wrote: > > > The tutorial is misleading on this. It it says plainly: > > > > A module can contain executable statements as well as function > > definitions. […] They are executed only the *first* time the module > > is imported somewhere. > > > > http://docs.python.org/tutorial/modules.html> > > That's more than misleading. It's plain wrong. The example I gave demonstrates the "print __file__" statement getting executed twice. > > The footnote to that is wrong too: > > > [1] In fact function definitions are also ‘statements’ that are ‘executed’; the execution of a > > module-level function enters the function name in the module’s global symbol table. > > I think what it's supposed to say is "... the execution of a module-level def statement ..." > > > Care to file a documentation bug http://bugs.python.org/> > > describing this? > > Sure, once I understand how it's really supposed to work :-) > > -- Each module only gets imported once. But if the same module can be accessed as two different names, python doesn't recognize that they are the same module. Along the same lines, if you create a symlink to the file, you'll be able to import the same module twice. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unexpected behavior using contextmanager on a class method
Thomas Draper wrote: > I want to use with..as in a "reversible circuit generator". However, it > seems that @contextmanager changes the expected nature of the class. I > tried to distill the problem down to a simple example. > > import contextlib > > class SymList: The problem you experience has nothing to do with context managers, you have a mutable default argument in your __init__(). > def __init__(self, L=[]): L is initialised with an empty list exactly once, when the method is defined; any changes you make to the list will be seen by all instances that use the default. The fix is def __init__(self, L=None): if L is None: L = [] > self.L = L > > @contextlib.contextmanager > def SymAdd(self, a): > self.L.append(a) > yield > self.L.append(a) > > SL = SymList() > with SL.SymAdd(3): > SL.L.append(5) > print(SL.L) # Expect and see [3, 5, 3] > SL2 = SymList() # New object. Should have default values. > print(SL2.L) # Expect [] and see [3, 5, 3] > > Why is the data member SL2.L referring to the data member SL.L? Has the > @contextmanager somehow made all instantions of the class related? -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
Roy Smith writes: >> In general, you should avoid non-idempotent code. > I don't understand your aversion to non-idempotent code as a general > rule. Most code is non-idempotent. Surely you're not saying we > should never write: foo += 1 > or my_list.pop() > ??? I don't think "in general avoid" means the same thing as "never write". One of the tenets of the functional-programming movement is that it is in fact reasonable to write in a style that avoids "foo += 1" and "my_list.pop()" most of the time, leading to cleaner, more reliable code. In Python it's not possible to get rid of ALL of the data mutation without horrendous contortions, but it's pretty easy (and IMHO of worthwhile benefit) to avoid quite a lot of it. -- http://mail.python.org/mailman/listinfo/python-list
RE: Object Models - decoupling data access - good examples ?
Given that "the customer is always right": In the past I've dealt with this situation by creating one or more "query" classes and one or more edit classes. I found it easier to separate these. I would then create basic methods like EditStaff.add_empooyee(**kwargs) inside of which I would drop into (in my case) MySQLdb. In retrospect, I'm not sure that the generick use of **kwargs was a good solution in that it masked what I was passing in, requiring me to go back to the calling code when debugging. OTOH it allowed me to be pretting generic by using Sql = sql_template % kwargs On the query side. I would convert the returned list of dictionaries to a list of objects using something like Class DBrecord: Def __init__(self, **kwargs): Self.__dict__.update(kwargs) So that I did not have to use the record['fieldname'] syntax but could use record.fieldname. I would describe myself as more of a survivalist programmer, lacking some of the sophisticated techniques of others on the mailing list so take that into account. Fred. -Original Message- From: python-list-bounces+frsells=adventistcare@python.org [mailto:python-list-bounces+frsells=adventistcare@python.org] On Behalf Of shearich...@gmail.com Sent: Saturday, August 04, 2012 11:26 PM To: python-list@python.org Subject: Re: Object Models - decoupling data access - good examples ? > > Just out of curiosity, why do you eschew ORMs? > Good question ! I'm not anti-ORM (in fact in many circs I'm quite pro-ORM) but for some time I've been working with a client who doesn't want ORMs used (they do have quite good reasons for this although probably not as good as they think). I was interested to know, given that was the case, how you might - in Python, go about structuring an app which didn't use an ORM but which did use a RDBMS fairly intensively. I take your point about having "rolled my own ORM" - lol - but I can assure you what's in that 'bardb' is a pretty thin layer over the SQL and nothing like the, pretty amazing, functionality of, for instance, SQLAlchemy. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Unexpected behavior using contextmanager on a class method
I want to use with..as in a "reversible circuit generator". However, it seems that @contextmanager changes the expected nature of the class. I tried to distill the problem down to a simple example. import contextlib class SymList: def __init__(self, L=[]): self.L = L @contextlib.contextmanager def SymAdd(self, a): self.L.append(a) yield self.L.append(a) SL = SymList() with SL.SymAdd(3): SL.L.append(5) print(SL.L) # Expect and see [3, 5, 3] SL2 = SymList() # New object. Should have default values. print(SL2.L) # Expect [] and see [3, 5, 3] Why is the data member SL2.L referring to the data member SL.L? Has the @contextmanager somehow made all instantions of the class related? -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
On Tuesday, August 7, 2012 9:55:16 AM UTC-4, Ben Finney wrote: > The tutorial is misleading on this. It it says plainly: > > A module can contain executable statements as well as function > definitions. […] They are executed only the *first* time the module > is imported somewhere. > > http://docs.python.org/tutorial/modules.html> That's more than misleading. It's plain wrong. The example I gave demonstrates the "print __file__" statement getting executed twice. The footnote to that is wrong too: > [1] In fact function definitions are also ‘statements’ that are ‘executed’; > the execution of a > module-level function enters the function name in the module’s global symbol > table. I think what it's supposed to say is "... the execution of a module-level def statement ..." > Care to file a documentation bug http://bugs.python.org/> > describing this? Sure, once I understand how it's really supposed to work :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
On Tuesday, August 7, 2012 9:52:59 AM UTC-4, Steven D'Aprano wrote: > In general, you should avoid non-idempotent code. You should > doubly avoid it during imports, and triply avoid it on days ending with Y. I don't understand your aversion to non-idempotent code as a general rule. Most code is non-idempotent. Surely you're not saying we should never write: >>> foo += 1 or >>> my_list.pop() ??? Making top-level module code idempotent, I can understand (given this new-found revelation that modules aren't really singletons), but you seem to be arguing something stronger and more general. -- http://mail.python.org/mailman/listinfo/python-list
Re: looking for a neat solution to a nested loop problem
On Mon, 06 Aug 2012 21:02:33 -0700, Larry Hudson wrote: >> for i in range(N,N+100): >> for j in range(M,M+100): >> do_something(i % 100 ,j % 100) >> >> Emile > > How about... > > for i in range(100): > for j in range(100): > do_something((i + N) % 100, (j + M) % 100) Both of these approaches move the modifications to the sequence into the body of the loop. It may be preferable to iterate over the desired sequence directly. E.g. for i in ((N + ii) % 100 for ii in xrange(100)): for j in ((M + jj) % 100 for jj in xrange(100)): do_something(i, j) -- http://mail.python.org/mailman/listinfo/python-list
Re: Procedure to request adding a module to the standard library - or initiating a vote on it
Helmut Jarausch wrote: > On Tue, 07 Aug 2012 13:15:29 +0200, Peter Otten wrote: > >> I don't think that will help. From PEP 408: >> >> """ >> As part of the same announcement, Guido explicitly accepted Matthew >> Barnett's 'regex' module [4] as a provisional addition to the standard >> library for Python 3.3 (using the 'regex' name, rather than as a drop-in >> replacement for the existing 're' module). >> """ > > What is a "provisional addition"? My understanding is that Guido agreed for it to be added under a different name (i. e. as regex, not re) and with no guarantees that it will remain in Python versions above 3.3. > Python-3.3 (20120708) doesn't have such a module. Indeed. Guido allowed adding the module, but some core devs remained skeptical and no one put in the legwork to add it. It may still be added in 3.4 if a core developer is willing to familiarise with the codebase and promises to help with maintenance, but the chances seem low by now. -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a good introduction to object oriented programming with Python
On Aug 7, 7:34 pm, lipska the kat wrote: > > Never thought so for a moment, good to know you can be reasonable as > well as misguided ;-) Well Lipska I must say that I find something resonant about the 'no- person' thing, though I am not sure what. You also said something about 'user' being more acceptable. From a different (opposite?) angle Dijkstra seems to be saying the same thing, here: http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD618.html Wonder what you make of it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Procedure to request adding a module to the standard library - or initiating a vote on it
On 07/08/2012 15:47, Helmut Jarausch wrote: On Tue, 07 Aug 2012 13:15:29 +0200, Peter Otten wrote: I don't think that will help. From PEP 408: """ As part of the same announcement, Guido explicitly accepted Matthew Barnett's 'regex' module [4] as a provisional addition to the standard library for Python 3.3 (using the 'regex' name, rather than as a drop-in replacement for the existing 're' module). """ What is a "provisional addition"? Python-3.3 (20120708) doesn't have such a module. Many thanks, Helmut. This is a new concept, as an example see http://bugs.python.org/issue14814#msg164795 which refers to the implementation of PEP 3144, the ipaddress module. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Procedure to request adding a module to the standard library - or initiating a vote on it
On Tue, 07 Aug 2012 13:15:29 +0200, Peter Otten wrote: > I don't think that will help. From PEP 408: > > """ > As part of the same announcement, Guido explicitly accepted Matthew > Barnett's 'regex' module [4] as a provisional addition to the standard > library for Python 3.3 (using the 'regex' name, rather than as a drop-in > replacement for the existing 're' module). > """ What is a "provisional addition"? Python-3.3 (20120708) doesn't have such a module. Many thanks, Helmut. -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
On 2012-08-07 15:55, Ben Finney wrote: Roy Smith writes: So, it appears that you *can* import a module twice, if you refer to it by different names! This is surprising. The tutorial is misleading on this. It it says plainly: A module can contain executable statements as well as function definitions. […] They are executed only the *first* time the module is imported somewhere. http://docs.python.org/tutorial/modules.html> but it doesn't make clear that a module can exist in the ‘sys.modules’ list multiple times under different names. sys.modules is a dict. But yes, there can be multiple "instances" of the same module loaded. What I do with bigger projects is that I always use absolute module names. For example, when I develop a project called "project1" that has several sub packages, then I always do these kinds of imports: from project1.package1.subpackage2.submodule3 import * from project1.package1.subpackage2 import submodule3 from project1.package1.subpackage2.submodule3 import some_class Even from a source file that is inside project1.package1.subpackage2, I tend to import them the same way. This makes sure that every module is imported under the same package path. You just need to make sure that the main project has a unique name (which is usually the case) and that it is on your sys path (which is usually the case, especially when the script is started in the project's directory). The cost is that you have to type more. The benefit is that you can be sure that you are importing the thing that you want to import, and there will be no multiple imports for the same module. Mabye somebody will give method that works even better. For small projects without sub-packages, it is not a problem. Best, Laszlo -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 07/08/12 15:14, Steven D'Aprano wrote: On Tue, 07 Aug 2012 10:19:31 +0100, lipska the kat wrote: On 07/08/12 06:19, Steven D'Aprano wrote: [...] But what *really* gets me is not the existence of poor terminology. I couldn't care less what terminology Java programmers use among themselves. I'd be most grateful if you could park the whole 'This person is a 'Java developer so must be a moron thing' it's getting a bit wearing. Lipska, it's not always about you. Never thought so for a moment, good to know you can be reasonable as well as misguided ;-) lipska -- Lipska the Kat: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On Tue, 07 Aug 2012 10:19:31 +0100, lipska the kat wrote: > On 07/08/12 06:19, Steven D'Aprano wrote: [...] >> But what *really* gets me is not the existence of poor terminology. I >> couldn't care less what terminology Java programmers use among >> themselves. > > I'd be most grateful if you could park the whole 'This person is a 'Java > developer so must be a moron thing' it's getting a bit wearing. Lipska, it's not always about you. I've been hanging around this forum for, oh, at least six years now. Trust me, you're not the first Java developer brave enough to poke their head up :) Java coders who come here tend to talk about "instance variables". C++ coders tend to talk about "members". Haskell people don't tend to talk much about objects at all. And PHP coders tend to talk about how they saw Spot run. (I kid. Sorry PHP coders, I couldn't resist.) It's not about being a moron. Anyone new to a language is going to carry across preconceptions from their previous language, and use the terminology they're used to. I've seen more than one Lisper assume that Python lists are linked lists and wonder how to call car and cdr, and nobody is accusing Lispers of being dumb. And I'm not going to even try to describe the misconceptions I had learning Python, coming from a background of Pascal, RPN and Hypertalk -- the first two languages weren't OOP, and Hypertalk's OOP model was *very* different from Python's. Don't think that every time I mention Java it's a dig at you. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 07/08/12 14:12, Ben Finney wrote: lipska the kat writes: The ONLY concept that you should never try to encapsulate is/are human beings or their aliases. You stated this in absolute, dogmatic terms. I thought at first you were being hyperbolic for effect, but the situation that you present to support this dogma is one where I can't see anyone rationally concluding the dogma applies. Ah, you mean you don't agree. Well now this is a personal thing born of bitter experience. [snip] Also, inevitably a Person 'is a' Customer, a Person 'is a' Contact, a Person 'is a' security risk, well you get the idea. This accurately reflects the reality that “person” is a real-world entity very frequently involved in just about anything a typical system needs to model. No, you are wrong. Having a Person class is profoundly and fundamentally wrong. If we follow this argument then every system ever modelled would have a Person at it's heart. I think you are missing the point here. You say. > This accurately reflects the reality that “person” is a real-world > entity very frequently involved in just about anything a typical stem > needs to model. that a "person" is a real-world entity very >frequently Have asserted that you are profoundly wrong I now have to say that I couldn't agree more BUT with the crucial modifier that a person is an "actor" I don't care if you like or dislike the terminology, you get the general idea. An actor exists outside the system. Having a Person in the Class model tends to blur the boundaries between system and users. I know it does, I've seen it happen so many times. It's all about how we think about a system in the early stages of design The moment we introduce a Person (or alias for a Person) we confuse our thinking, are we thinking about Person as actor or are we thinking about Person as entity in our system. This is not some nebulous flight of fancy, this is born of real world, stand at the whiteboard and thrash out a design experience. I have been ridiculed before, strangely enough, once the Person has been expunged from the system mind things go a whole lot more smoothly. Of course this is a problem with the actual design process itself What problem? If the real-world entity really exists and the “has-a” and “is-a” relationships really exist, then it's *good* design to model whatever ones of those are significant to the operation of the program. Indeed, it would be *bad* design to avoid modelling the real world merely because of dogma against modelling persons and their relationships to other entities. Dogma is an emotive word that you are using to belittle the idea. That's fine, you asked me to explain myself and I have done so. [snip] And when the real domain to be modelled almost certainly has people as a central entity in complex interactions, removing Person from the design entirely is poor work grounded in irrationality. Well I say it's sound judgment grounded in experience and most if not all my employers seem to agree. I have thousands of lines of code 'in the wild' operating without fault day after week after year and not one single line refers to, implies or otherwise represents a "Person" in any way whatsoever. Just one tiny point, I NEVER have to 'remove' a Person from my designs as they never get through the door in the first place. The only time I have ever had to agree that a "Person" belongs in a computer is when I saw Tron. lipska -- Lipska the Kat: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
On 07/08/2012 14:28, Ramchandra Apte wrote: I don't think the modules are actually imported twice. The entry is just doubled;that's all Please don't top post, this is the third time of asking. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Intermediate Python user needed help
On Monday, August 6, 2012 11:39:45 PM UTC-4, Dennis Lee Bieber wrote: > On Tue, 7 Aug 2012 07:59:44 +1000, Chris Angelico > > declaimed the following in gmane.comp.python.general: > > > > > On Tue, Aug 7, 2012 at 5:22 AM, Dennis Lee Bieber > > wrote: > > > > So am I beginner, intermediate, advanced, expert? > > > > > > I wonder would this sort of a scale help: > > > > > > http://www.geekcode.com/geek.html#perl > > > > > > Novice: P > > > Intermediate: P+ or P++ > > > Advanced: P+++ > > > Master: P > > > > > Surely we can rise above mere "pluses" and rank using "stars" (*) -- > > a four-star Pythoneer (or whatever the preferred term is)? > > > > -- > > Wulfraed Dennis Lee Bieber AF6VN > > wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/ No matter what level you are in python you will still make mistakes every once in a while but if your like a expert you just notice it faster -- http://mail.python.org/mailman/listinfo/python-list
Re: Procedure to request adding a module to the standard library - or initiating a vote on it
On 07/08/2012 11:13, Helmut Jarausch wrote: Hi, I'd like to request adding the module http://pypi.python.org/pypi/regex to Python's standard library in the (near) future or to even replace the current 're' module by it. Personally I'm in need for fuzzy regular expressions and I don't see how to do this easily and efficiently without this module. For a long term project I also need some "guarantee" that this functionality will exist in future. So, is there a (formal) procedure for such a request or for initiating some sort of vote on it? I know there is a "Benevolent Dictator" for Python. Should I try to contact him personally? Many thanks for a hint, Helmut Jarausch RWTH Aachen University Germany My understanding is that the main stumbling block is there's no one committed to being the maintainer of the code. If that commitment is not made, and I belive it's required to be several (10?) years, then the code may never get into the standard library. I'll happily stand corrected if anyone knows any better. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
Roy Smith writes: > So, it appears that you *can* import a module twice, if you refer to > it by different names! This is surprising. The tutorial is misleading on this. It it says plainly: A module can contain executable statements as well as function definitions. […] They are executed only the *first* time the module is imported somewhere. http://docs.python.org/tutorial/modules.html> but it doesn't make clear that a module can exist in the ‘sys.modules’ list multiple times under different names. Care to file a documentation bug http://bugs.python.org/> describing this? > It means that having non-idempotent code which is executed at import > time is a Bad Thing. This is true whether or not the above about module imports is true. A well-designed module should have top level code that performs idempotent actions. Be thankful that you've discovered this, and apply it well :-) -- \ “See, in my line of work you gotta keep repeating things over | `\ and over and over again, for the truth to sink in; to kinda | _o__) catapult the propaganda.” —George W. Bush, 2005-05 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
On Tue, 07 Aug 2012 09:18:26 -0400, Roy Smith wrote: > I thought modules could not get imported twice. The first time they get > imported, they're cached, and the second import just gets you a > reference to the original. Playing around, however, I see that it's > possible to import a module twice if you refer to it by different names. Yes. You've found a Python gotcha. The most common example of this is when a single file acts as both an importable module, and as a runnable script. When run as a script, it is known as "__main__". When imported, it is known by the file name. Unless you take care, it is easy to end up with the module imported twice. The usual advice is "never have one module used as both script and importable module". I think *never* is a bit strong, but if you do so, you need to take extra care. > Here's a small-ish test case which demonstrates what I'm talking about > (python 2.6.5): > > In directory /home/roy/play/import/foo, I've got: > > __init__.py (empty file) > try.py > broken.py Aside: calling a module "try.py" is asking for trouble, because you can't do this: import try > $ cat broken.py > print __file__ > > > $ cat try.py > import broken > import foo.broken Which are two names for the same module. > So, it appears that you *can* import a module twice, if you refer to it > by different names! This is surprising. It means that having > non-idempotent code which is executed at import time is a Bad Thing. Well yes. In general, you should avoid non-idempotent code. You should doubly avoid it during imports, and triply avoid it on days ending with Y. The rest of the time, it is perfectly safe to have non-idempotent code. :) I kid, of course, but only half. Side-effects are bad, non-idempotent code is bad, and you should avoid them as much as possible, and unless you have no other reasonable choice. > It also means that you could have multiple copies of a module's global > namespace, depending on how your users imported the module. Which is > kind of mind-blowing. Oh that part is trivial. Module namespaces are just dicts, there's nothing special about them. py> import math # for example py> import copy py> namespace = copy.deepcopy(math.__dict__) py> math.__dict__ == namespace True py> math.__dict__ is namespace False It are modules which should be special, and Python tries really hard to ensure that they are singletons. (Multitons?) But not superhumanly hard. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Models - decoupling data access - good examples ?
On Sat, 2012-08-04 at 20:26 -0700, shearich...@gmail.com wrote: > > > > Just out of curiosity, why do you eschew ORMs? > Good question ! > I'm not anti-ORM (in fact in many circs I'm quite pro-ORM) but for > some time I've been working with a client who doesn't want ORMs used > (they do have quite good reasons for this although probably not as > good as they think). So call the ORM something else. > I was interested to know, given that was the case, how you might - in > Python, go about structuring an app which didn't use an ORM but which > did use a RDBMS fairly intensively. You'd reinvent the ORM calling it something else - because an ORM is what you are describing. This is just a case of those-who-will-not-use-are-doomed-to-recreate. > I take your point about having "rolled my own ORM" - lol - but I can > assure you what's in that 'bardb' is a pretty thin layer over the SQL > and nothing like the, pretty amazing, functionality of, for instance, > >SQLAlchemy. This implies that SQLAlchemy is 'fat'. I don't see any evidence of that. It is comprehensive so when you encounter something you can be confident it is up to the challange. signature.asc Description: This is a digitally signed message part -- http://mail.python.org/mailman/listinfo/python-list
Re: I thought I understood how import worked...
I don't think the modules are actually imported twice. The entry is just
doubled;that's all
On 7 August 2012 18:48, Roy Smith wrote:
> I've been tracking down some weird import problems we've been having with
> django. Our settings.py file is getting imported twice. It has some
> non-idempotent code in it, and we blow up on the second import.
>
> I thought modules could not get imported twice. The first time they get
> imported, they're cached, and the second import just gets you a reference
> to the
> original. Playing around, however, I see that it's possible to import a
> module
> twice if you refer to it by different names. Here's a small-ish test case
> which
> demonstrates what I'm talking about (python 2.6.5):
>
> In directory /home/roy/play/import/foo, I've got:
>
> __init__.py (empty file)
> try.py
> broken.py
>
>
> $ cat broken.py
> print __file__
>
>
> $ cat try.py
> import broken
> import foo.broken
>
> import sys
> for m in sys.modules.items():
> if m[0].endswith('broken'):
> print m
>
>
> And when I run try.py (with foo as the current directory):
>
> $ PYTHONPATH=/home/roy/play/import python try.py
> /home/roy/play/import/foo/broken.pyc
> /home/roy/play/import/foo/broken.pyc
> ('broken', )
> ('foo.broken', '/home/roy/play/import/foo/broken.pyc'>)
>
>
> So, it appears that you *can* import a module twice, if you refer to it by
> different names! This is surprising. It means that having non-idempotent
> code
> which is executed at import time is a Bad Thing.
>
> It also means that you could have multiple copies of a module's global
> namespace, depending on how your users imported the module. Which is kind
> of
> mind-blowing.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
I thought I understood how import worked...
I've been tracking down some weird import problems we've been having with
django. Our settings.py file is getting imported twice. It has some
non-idempotent code in it, and we blow up on the second import.
I thought modules could not get imported twice. The first time they get
imported, they're cached, and the second import just gets you a reference to
the
original. Playing around, however, I see that it's possible to import a module
twice if you refer to it by different names. Here's a small-ish test case
which
demonstrates what I'm talking about (python 2.6.5):
In directory /home/roy/play/import/foo, I've got:
__init__.py (empty file)
try.py
broken.py
$ cat broken.py
print __file__
$ cat try.py
import broken
import foo.broken
import sys
for m in sys.modules.items():
if m[0].endswith('broken'):
print m
And when I run try.py (with foo as the current directory):
$ PYTHONPATH=/home/roy/play/import python try.py
/home/roy/play/import/foo/broken.pyc
/home/roy/play/import/foo/broken.pyc
('broken', )
('foo.broken', )
So, it appears that you *can* import a module twice, if you refer to it by
different names! This is surprising. It means that having non-idempotent code
which is executed at import time is a Bad Thing.
It also means that you could have multiple copies of a module's global
namespace, depending on how your users imported the module. Which is kind of
mind-blowing.
--
http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
lipska the kat writes: > The ONLY concept that you should never try to encapsulate is/are > human beings or their aliases. You stated this in absolute, dogmatic terms. I thought at first you were being hyperbolic for effect, but the situation that you present to support this dogma is one where I can't see anyone rationally concluding the dogma applies. > Well now this is a personal thing born of bitter experience. In my > experience, when you have an entity called 'Person' or some such in > your Class model it soon becomes what we 'in the trade' call a 'God > Object' The name should be self explanatory but hold tight, here comes > some more jargon. God objects are a code smell (another term of art, meaning a symptom in the code that tends to indicate poor design or some other fundamental flaw). But what you're describing below doesn't fit. > Objects can have a 'has a' relationship with other Objects or an 'is a' > relationship with other objects > > The 'has a' relationship means that an Object 'owns' another object, > the is a' relationship means that an Object 'is of a particular type' > Of course in an 'Object Oriented' language such as Java an Object > reference can have a different type at runtime than it does at compile > time. In Python too. > > Anyway, this Person thing soon ends up with a 'has a' relationship > with everything in sight. a Person 'has a[n]' Address, a Person 'has > a[n]' account, a Person 'has a' Doughnut etc etc etc > > Also, inevitably a Person 'is a' Customer, a Person 'is a' Contact, a > Person 'is a' security risk, well you get the idea. This accurately reflects the reality that “person” is a real-world entity very frequently involved in just about anything a typical system needs to model. > Of course this is a problem with the actual design process itself What problem? If the real-world entity really exists and the “has-a” and “is-a” relationships really exist, then it's *good* design to model whatever ones of those are significant to the operation of the program. Indeed, it would be *bad* design to avoid modelling the real world merely because of dogma against modelling persons and their relationships to other entities. If there were entities or relationships that were needlessly cumbersome – if indeed the object was trying to encapsulate the majority of the whole world in itself – then those should be removed from the object, and perhaps even from the design. But that's not what you describe. A Person entity in inheritance or composition relationships with other classes and objects is not a god object, since it is sensibly delegating specific jobs to places other than itself. That's very good, modular design. And when the real domain to be modelled almost certainly has people as a central entity in complex interactions, removing Person from the design entirely is poor work grounded in irrationality. -- \ “I am amazed, O Wall, that you have not collapsed and fallen, | `\since you must bear the tedious stupidities of so many | _o__) scrawlers.” —anonymous graffiti, Pompeii, 79 CE | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Pickle file and send via socket
On 07/08/12 12:21, S.B wrote: Can anyone provide a simple code example of the client and server sides? Working on it lipska -- Lipska the Kat: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun -- http://mail.python.org/mailman/listinfo/python-list
Re: find out whether a module exists (without importing it)
You are correct. On 7 August 2012 14:38, Chris Angelico wrote: > On Tue, Aug 7, 2012 at 6:00 PM, Gelonida N wrote: > > modulename = 'my.module' > > cmd = 'import %s as amodule' > > try: > > exec(cmd) > > print "imported successfully" > > Someone will doubtless correct me if I'm wrong, but I think you can > avoid exec here with: > > amodule=__import__(modulename) > > ChrisA > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Pickle file and send via socket
On Monday, August 6, 2012 4:32:13 PM UTC+3, S.B wrote: > Hello friends > > > > Does anyone know if it's possible to pickle and un-pickle a file across a > network socket. i.e: > > First host pickles a file object and writes the pickled file object to a > client socket. > > Second host reads the pickled file object from the server socket and > un-pickles it. > > > > Can anyone provide a simple code example of the client and server sides? > > > > Thanks Lot's of conflicting answers :-( Can anyone provide a simple code example? -- http://mail.python.org/mailman/listinfo/python-list
Re: Procedure to request adding a module to the standard library - or initiating a vote on it
Helmut Jarausch wrote: > I'd like to request adding the module > > http://pypi.python.org/pypi/regex > > to Python's standard library in the (near) future or to even replace the > current 're' module by it. > > Personally I'm in need for fuzzy regular expressions and I don't see how > to do this easily and efficiently without this module. > > For a long term project I also need some "guarantee" that this > functionality will exist in future. There has been a discussion about that particular module, and it would have gone into 3.3 if it were not for the low "bus count" (only the author having working knowledge of the code). > So, is there a (formal) procedure for such a request or for initiating > some sort of vote on it? > > I know there is a "Benevolent Dictator" for Python. > Should I try to contact him personally? I don't think that will help. From PEP 408: """ As part of the same announcement, Guido explicitly accepted Matthew Barnett's 'regex' module [4] as a provisional addition to the standard library for Python 3.3 (using the 'regex' name, rather than as a drop-in replacement for the existing 're' module). """ -- http://mail.python.org/mailman/listinfo/python-list
Re: OT probably but still relevant (was Re: Looking for a good introduction to object oriented programming with Python)
On 07/08/12 10:44, Steven D'Aprano wrote: On Mon, 06 Aug 2012 17:23:19 +0100, lipska the kat wrote: On 06/08/12 13:19, rusi wrote: I suggest this http://steve-yegge.blogspot.in/2006/03/execution-in-kingdom-of- nouns.html http://bpfurtado.livejournal.com/2006/10/21/ Unfortunately the author (Bruno Furtado) has missed the point. He seems Steve, chill out, you seem to have this whole Javahate thing going at the moment. It's just a language, like Python. You can write crap code in Java just like you can write crap code in any language. Just for the record 'Time' is way too complex a concept to encapsulate in a single class (we can debate that if you like although it all gets a bit philosophical) If you MUST have a Time Object in Java you can instantiate java.sql.Time, not really that complicated is it ? I do enjoy debating with you but really, lighten up a bit, it really isn't that important, mankind existed for millenia before computers and programming languages. If we want to exist for millenia after their invention then we need to get off this planet. If you want to get excited about something then get excited about our apparent inability to exceed the speed of light. Until we solve that one we are doomed. I'm thinking of adding a line to my sig for this group that says "I don't hate Python, I like it for it's differences" ;-) lipska -- Lipska the Kat: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun -- http://mail.python.org/mailman/listinfo/python-list
Procedure to request adding a module to the standard library - or initiating a vote on it
Hi, I'd like to request adding the module http://pypi.python.org/pypi/regex to Python's standard library in the (near) future or to even replace the current 're' module by it. Personally I'm in need for fuzzy regular expressions and I don't see how to do this easily and efficiently without this module. For a long term project I also need some "guarantee" that this functionality will exist in future. So, is there a (formal) procedure for such a request or for initiating some sort of vote on it? I know there is a "Benevolent Dictator" for Python. Should I try to contact him personally? Many thanks for a hint, Helmut Jarausch RWTH Aachen University Germany -- http://mail.python.org/mailman/listinfo/python-list
Re: OT probably but still relevant (was Re: Looking for a good introduction to object oriented programming with Python)
On Mon, 06 Aug 2012 17:23:19 +0100, lipska the kat wrote:
> On 06/08/12 13:19, rusi wrote:
>> I suggest this
>> http://steve-yegge.blogspot.in/2006/03/execution-in-kingdom-of-
nouns.html
>
> http://bpfurtado.livejournal.com/2006/10/21/
Unfortunately the author (Bruno Furtado) has missed the point. He seems
to think that Kingdom of Nouns ("the Rant") is an anti-OO screed. It is
not. There is more to OO than Java, and criticism of Java does not mean
"objects are bad".
Nor is it that Kingdom of Nouns believes the problem is "Two lines per
source code file!!!". It isn't just that two extra lines when you declare
a function. It is the extraneous, unnecessary extra layer each time you
read (or write, but mostly read) the method, and the ever-more abstract,
deep layers of Builders, Getters, Setters, Doers and so forth.
In Python, occasionally you will come across code like this:
value = time.time()
which is the time function in the time module. Pretty skanky, right? It's
not likely that you have a whole bunch of spam.time, foo.time,
physics.time etc. in your code base, right? If you do, then maybe this is
justified, but how often does that happen?
Having that duplicated time.time is a code smell that says "you might
have too many code layers here, better look at this a bit more closely".
Now imagine if this was a more Java-ish language:
value = time.time.time()
where you have method time of class time in module time. And you have to
call it that way *all the time* (pun not intended).
That's not so much a "might" have too many layers, as "almost certainly".
In Java, all those dot look-ups happen at compile time and are fast. In
Python, they happen at runtime, and while they're still often fast,
sometimes they can be slow. But that's not the real problem. The real
problem is reading and writing it.
Python solves that two ways:
1) Modules, classes, methods and functions are first-class objects, so
you can do this:
from time import time
# or if you prefer, "import time; time = time.time"
value = time()
2) It doesn't force you to use the same number of layers for
*everything*. If you have code that will benefit from two, or three, or
seventeen, layers, you are free to do so:
value = (time.time() + spacetime.Time.time() - Spam.time.flavour()
+ Cube.time())
And if not, then don't:
value = time() + spacetime.time() - flavour() + Cube.time()
It is this which is the point of Kingdom of Nouns. It is not an anti-OO
screed. It is not an argument against namespaces, or encapsulation, or
especially not that Java methods take an extra "Two lines per source
file". It is that Java forces a single mental model on you, all the time,
whether it makes for better, more readable code or not.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 07/08/12 06:19, Steven D'Aprano wrote: On Mon, 06 Aug 2012 09:55:24 +0100, lipska the kat wrote: On 06/08/12 01:22, Steven D'Aprano wrote: On Sun, 05 Aug 2012 20:46:23 +0100, lipska the kat wrote: [snip] The clue is in the name 'Object Oriented' ... anything else is (or should be) implementation detail. So your argument is that any programming which is "oriented" (meaning what?) towards "objects" (which are...?) is OOP, and everything else is "implementation detail". Well now I'm enlightened. That certainly clears that up for me. Glad I could help :-) [snip] As you go on to explain: A class variable is static and can be accessed without instantiation an instance variable is accessed via an instance which are semantic differences, differences in meaning and function. Yes but when we TALK about these things a String variable is a String variable is a String variable. The words 'Class variable' and 'instance variable' are 'abstractions'. It saves us saying, 'this is a variable that can only be accessed from an instance and may hold values of the type Integer or String or Weak Reference ... (and so on ad nauseum) ... but only of one type unless you count runtime polymorphism in which case the runtime type may be different from the compile time type ... etc etc' or 'this is a variable that can be accessed without instantiating a class (see above)' If you don't like the term abstraction then perhaps we can agree on something else. Since a "string variable" is a variable holding a string, and a "float variable" is a variable holding a float, an instance variable should be a variable holding an instance, and a class variable should be a variable holding a class. See above Class variable and instance variable are higher level abstractions. Of what? Of variables? Exactly, now you're getting the hang of it [snip] Simply put, the choice of terminology is crap -- possibly but it's the best we've got. But what *really* gets me is not the existence of poor terminology. I couldn't care less what terminology Java programmers use among themselves. I'd be most grateful if you could park the whole 'This person is a 'Java developer so must be a moron thing' it's getting a bit wearing. As I said in a previous post, Java has indeed been good to me but my brain IS capable of dealing with more than one language. What gets me is that the ubiquity of them means that substandard terminology spreads into other languages, like dryrot. Yea well welcome to the world of spin, if you can't fight it then learn to roll with it. The ONLY concept that you should never try to encapsulate is/are human beings or their aliases. snip Is this some sort of mystical "humans aren't objects, they're SPECIAL!!!" rubbish? Because it sure sounds like it. [snip] Well now this is a personal thing born of bitter experience. In my experience, when you have an entity called 'Person' or some such in your Class model it soon becomes what we 'in the trade' call a 'God Object' The name should be self explanatory but hold tight, here comes some more jargon. Objects can have a 'has a' relationship with other Objects or an 'is a' relationship with other objects The 'has a' relationship means that an Object 'owns' another object, the 'is a' relationship means that an Object 'is of a particular type' Of course in an 'Object Oriented' language such as Java an Object reference can have a different type at runtime than it does at compile time. In Python too. Anyway, this Person thing soon ends up with a 'has a' relationship with everything in sight. a Person 'has a[n]' Address, a Person 'has a[n]' account, a Person 'has a' Doughnut etc etc etc Also, inevitably a Person 'is a' Customer, a Person 'is a' Contact, a Person 'is a' security risk, well you get the idea. Of course this is a problem with the actual design process itself and yes, the identification of the 'nouns in the language of the domain' is an important part of the process. Sorry, but it just works when it's done properly, I know it works as I used this technique to turn around this 'Person as God' design from a failing money pit into a working system that delivered (almost) on time. The very first thing I did was to exorcise Person from the design. I've already managed to write meaningful code but I haven't invented a single class yet. And why do you think this is a problem? A problem? I wasn't ware that I'd stated it was a problem it just You said "BUT [emphasis added] I haven't invented a single class yet", which implies that this is a bad thing [snip] No it implies that I noticed it was possible to do meaningful work in Python without writing a class. Well this HAS been fun, I look forward to your reply but at the moment I have to go and pick some runner beans as it's been a fantastic year for beans and the freezer awaits. lipska -- Lipska the Kat: Troll hunter, sandbox destroyer
Re: find out whether a module exists (without importing it)
On Tue, Aug 7, 2012 at 6:00 PM, Gelonida N wrote: > modulename = 'my.module' > cmd = 'import %s as amodule' > try: > exec(cmd) > print "imported successfully" Someone will doubtless correct me if I'm wrong, but I think you can avoid exec here with: amodule=__import__(modulename) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: find out whether a module exists (without importing it)
Gelonida N wrote: > Is this possible. > > let's say I'd like to know whether I could import the module > 'mypackage.mymodule', meaning, > whther this module is located somewhere in sys.path > > i tried to use > > imp.find_module(), but > it didn't find any module name containing a '.' You could look for the toplevel name and then look for modules in the corresponding directory. This is not always reliable as a package may not correspond to a directory (e. g.: os and os.path), but I don't think you can get any closer without performing an actual import. -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 07/08/12 06:35, Steven D'Aprano wrote: On Mon, 06 Aug 2012 10:24:10 +0100, lipska the kat wrote: er, the point I was trying to make is that when you say 'interface' it could mean so many things. If you say 'facade' everyone knows exactly what you are talking about. And that is EXACTLY the point. The whole point of design patterns is to avoid getting stuck in incidental implementation details of a particular library or class and look for higher-level design patterns. The same applies to facade -- it's just a special case of the interface pattern. So you AGREE with me, fantastic, what are we arguing about then (it's great fun though isn't it) facade is a SPECIAL case of interface. You seem to be missing this point. I may not be as smart or experienced as you but in my fairly wide experience of software projects of all sizes the biggest problem is one of communication. Design patterns, in my experience help with communication. I have designed and implemented many facades, I have also designed many interfaces. I do not think Java is the be all and end all of programming languages but it has paid off my mortgage and provided me with a good living. Python interests me because it is different. As far as I can see if I'm talking with a Pythonista or a Java developer or a hardware engineer (possibly) or a C++ guru or a university lecturer or an Eiffel developer and I say 'interface' they will all visualise something slightly different, if I say 'facade' they will all (hopefully) know EXACTLY what I am talking about. lipska -- Lipska the Kat: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun -- http://mail.python.org/mailman/listinfo/python-list
Re: find out whether a module exists (without importing it)
Hi Michael, On 08/07/2012 08:43 AM, Michael Poeltl wrote: in my opinion, "without importing it" makes it unnecessarily complicated. It does, but I think this is what I want, thus my question. I tried to keep my question simple without explaining too much. Well now here's a little more context. There's two reasons why I sepcified the without importing it. Some modules may have side effects when being imported,and sometimes I just want to check for a module's existence Second: Sometimes I only want to know, whether a module exists. I do not want to know whether a module is syntactically correct or whether a module if imported is capable of importing all it's submodules What I'd like to achieve at the moment is to distinguish three situations: - a module with a given name does not exist - a module with a given name exists and produces errors (might be ImportErors) - a module with a given name exists and can be imported In fact what I really want to achieve is: import a module if it exists (and fail if it is broken) if it doesn't exist import a 'default' module and go on. The name of the module is stored in a variable and is not known prior to running the script so the code, that you suggested would be something like. modulename = 'my.module' cmd = 'import %s as amodule' try: exec(cmd) print "imported successfully" except ImportError: print "module doesn't exist or the module tries to " \ "import another module that doesn't exist" # if the module doesn't exist I'd like to import a 'fallback' module # otherwise I'd like to abort. except Exception as exc: print "module exists, but is broken" raise exc amodule.do_something() You just want to know it module xyz exists, or better said can be found (sys.path). why not try - except[ - else ] try: import mymodule except ImportError: # NOW YOU KNOW it does not exist #+ and you may react properly ?? * Gelonida N [2012-08-06 22:49]: Is this possible. let's say I'd like to know whether I could import the module 'mypackage.mymodule', meaning, whther this module is located somewhere in sys.path i tried to use imp.find_module(), but it didn't find any module name containing a '.' Am I doing anything wrong? Is there another existing implementation, that helps. I could do this manually, but this is something I'd just like to do if necessary. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a good introduction to object oriented programming with Python
On 07/08/2012 02:12, Steven D'Aprano wrote: On Mon, 06 Aug 2012 17:17:33 +0100, Mark Lawrence wrote: Please see my comment at the bottom hint hint :) Please trim unnecessary quoted text. We don't need to see the entire thread of comment/reply/reply-to-reply duplicated in *every* email. Point taken, sorry. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: dictionary comprehensions with Python 2.4/2.5
Not back to 2.5, but they're not that important anyway. Just use: d = dict((k, v) for k,v in ... ) Thank you very much! It is the perfect solution for me. Regards, Iryna. -- http://mail.python.org/mailman/listinfo/python-list
Re: dictionary comprehensions with Python 2.4/2.5
Iryna Feuerstein writes: > code. The dictionary comprehensions were added to Python in version > 2.7 at first time. Is it possible to make it compatible with Python > 2.5 anyway? Perhaps by using the __future__ module? Not back to 2.5, but they're not that important anyway. Just use: d = dict((k, v) for k,v in ... ) -- http://mail.python.org/mailman/listinfo/python-list
