Re: Recommendation for Object-Oriented systems to study

[Phuong Phan]

Hi All,

I think you all are very professional programmer and or working in IT
industry, teaching programming and so on. So I think it is quite funny that
you spent time to discuss about this topic.

I am not pro like you guys. I like programming. And when I think to develop
my career as an IT engineer, I also do not know which language I should
start, although, I know a bit C, Perl, Visual Basic. Luckily I found a free
course on edX teaching computer science using Python. I really surprised
that Python is so easy to learn. I like the beautiful simplicity at the
beginning of learning Python. Really impressive to me.

However, when I have chance to learn and work with other languages such as
C# and C++. I found that they are also supercool. At that time it is clear
to me that there is no best language. Each language has its good points. It
is up to you to use/explore it and develop it too.

So again, it is funny to me to ask which language should learn first, or
which language should be used to teach/learn OO. Now if someone asks me
which language should learn first, I would say it is C, definitely and no
doubt C.

By the way, now I bought some books about Python, OpenCV, and Robotics.
Time to enjoy Python now.
Regards,
Phuong
(By the way, I do not like snake image of Python much :-))


On Fri, Jun 3, 2016 at 2:14 PM, Bob Martin  wrote:

> in 760378 20160602 131534 Alan Evangelista 
> wrote:
> >On 06/02/2016 02:44 AM, Lawrence D�Oliveiro wrote:
> >> On Monday, May 30, 2016 at 7:17:47 AM UTC+12, Alan Evangelista wrote:
> >>> - Java forces everything to be implemented in OO model (classes)
> >> After you have spend a few months battering your head against the
> rigidity and verbosity of Java,
> >> you will run back to Python with a sense of relief.
> >
> >The point was which programming language was better to teach object
> oriented concepts,
> >rigidity and verbosity has nothing to do with this. Most of this
> discussion has leaned towards
> >other criteria beyond adherence to OO paradigm (eg static typing vs
> dynamic typing and
> >personal taste), so I have chosen to not continue it.
> >
> >For some reason, Java still one of the most used programming languages to
> teach OO
> >in universities. In real life projects, people has the freedom to choose
> whatever they
> >prefer, though.  =)
>
> Rarely; the employer usually decides which language(s) to use.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[BartC]

On 03/06/2016 02:05, Lawrence D’Oliveiro wrote:

On Friday, June 3, 2016 at 8:52:52 AM UTC+12, BartC wrote:

One major objection was that C's 'for' isn't really a for-statement at
all (as it is understood in most other languages that haven't just
copied C's version), but is closer to a 'while' statement.


Apart from having local loop variables that get initialized just once. Not 
something you can fake with a “while” statement.


It's not hard. For:

  for (int A=B; C; D) {BODY}

you just write:

  {int A=B;
   while (C) {
 BODY;
 D;
   }
  }



That’s what makes C’s for-statement so versatile.



That's if you're into that. I've only ever use local variables with 
function-wide scope.


If your concern is with optimising, other languages can just have a rule 
about the validity of a for-loop index variable when the loop 
terminates. That's impossible in C because, it being so general purpose, 
there is no such thing as a for-loop index:


  a=0; b=1;
  for (c=2; dwhich one is the loop index? So it is necessary to stick actual 
declarations within the loop. Messy.


(Sorry, we're getting away from Python somewhat!)

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

Re: for / while else doesn't make sense

[BartC]

On 03/06/2016 03:47, Lawrence D’Oliveiro wrote:

On Friday, June 3, 2016 at 8:52:52 AM UTC+12, BartC wrote:

Simple iterative for-loops are more of a DIY effort...


There is one case that Python handles more nicely than C. And that is iterating 
over a fixed set of values. E.g. in Python

for rendering in (False, True) :
...
#end for

versus the (slightly) more long-winded C:

for (bool rendering = false;;)
  {
...
if (rendering)
break;
rendering = true;
  } /*for*/



Just one case? Python is miles away from a C 'for'. There's:

- C's for loop, a glorified while loop where you have specify every 
single detail: for (i=a; i<=b; ++i), including writing your nominated 
loop index three times.


- A 'traditional' for loop, which iterates over the integers A to B or 0 
to N-1 without having to spell out everything: for i=a,b


- A 'forall' kind of loop which iterates over a set of values, which is 
what Python has: for i in x:


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

Re: Don't put your software in the public domain

[Steven D'Aprano]

On Thu, 2 Jun 2016 04:41 pm, Gregory Ewing wrote:

> Steven D'Aprano wrote:
> 
>> http://linuxmafia.com/faq/Licensing_and_Law/public-domain.html
> 
>  From that:
>> It might be ruled to create a global licence for unrestricted use. That
>  > licence might or might not then be adjudicated to be revocable by
>  > subsequent copyright owners (heirs, divorcing spouses, creditors).
> 
> If that's possible, then could said heirs, divorcing spouses
> and creditors also revoke supposedly permanent rights granted
> under an explicit licence? Or is putting the word "irrevocable"
> in the licence enough to prevent that?

Further thoughts on this question...

A licence is something like a contract, in that it is binding on both
parties unless mutually agreed by both parties. With something like the MIT
licence, there's no action that the licensee (the user of the software) can
do to void the contract. And since there is no expiry date, the licence
lasts forever, hence the author cannot unilaterally cancel the licence.
Even if subsequent copyright owners (heirs etc) stop distributing the
software to *new* users, existing licensees still have the right to
distribute the software.

On the other hand, the GPL can be revoked, since the licence requires the
users to do something: if you distribute software based on the GPLed code,
you must also distribute the source code under the same licence terms. If
the user fails to do so, then one of two things happen:

(1) If the GPL licence is valid, then they are in breach of the licence
terms, the licence is revoked, and they are not legally permitted to
distribute or use the software;

(2) If, as some people insist, the GPL licence is not valid, then they have
no valid licence, and are not legally permitted to distribute or use the
software.

That's why, for all the talk about the GPL never being held up in court,
*nobody* has ever challenged it in court. If they did, and failed, then
they would be in breach of copyright. If they succeeded, they would still
be in breach of copyright. Any user of GPLed software who challenged it
would be shooting themselves in the head: *either way*, win or lose, they
would be in breach of copyright law.


(Reminder: I am not a lawyer and this is not legal advice.)



-- 
Steven

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

EuroPython 2016 Keynote: Gaël Varoquaux

[M.-A. Lemburg]

We are pleased to announce our final keynote speaker for EuroPython
2016:


*** Gaël Varoquaux ***



About Gaël Varoquaux


Gaël Varoquaux is an INRIA faculty researcher working on data science
for brain imaging in the Neurospin brain research institute (Paris,
France).

His research focuses on modeling and mining brain activity in relation
to cognition. Years before the NSA, he was hoping to make
bleeding-edge data processing available across new fields, and he has
been working on a mastermind plan building easy-to-use open-source
software in Python.

He is a core developer of scikit-learn, joblib, Mayavi and nilearn, a
nominated member of the PSF, and often teaches scientific computing
with Python using the scipy lecture notes.

The Keynote:
Scientist meets web dev: how Python became the language of data
---

Python started as a scripting language, but now it is the new trend
everywhere and in particular for data science, the latest rage of
computing. It didn’t get there by chance: tools and concepts built by
nerdy scientists and geek sysadmins provide foundations for what is
said to be the sexiest job: data scientist.

"In my talk I’ll give a personal perspective, historical and
technical, on the progress of the scientific Python ecosystem,
from numerical physics to data mining.

I will discuss low-level technical aspects, such as how the Python
world makes it easy to move large chunks of number across code,
touch upon current exciting developments in scikit-learn and
joblib, but also talk about softer topics, such as project
dynamics or documentation, as software’s success is determined by
people."


With gravitational regards,
--
EuroPython 2016 Team
http://ep2016.europython.eu/
http://www.europython-society.org/


PS: Please forward or retweet to help us reach all interested parties:
https://twitter.com/europython/status/738669507724595200
Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multiple inheritance, super() and changing signature

[Nagy László Zsolt]

>
> In Python 3, that will be automatic and you don't need to worry about it.
I'm using Python 3. I'm aware of old style and new style classes in
Python 2.
>
>
> [...] 
>> class BootstrapDesktop(BootstrapWidget, BaseDesktop):
>> def __init__(self, appserver, session):
>> # there is NOTHING else here, it just connects bootstrap widget
>> implementation with desktop methods
>> super(BootstrapDesktop, self).__init__(appserver, session)
> The correct way to do that is to simply not define an __init__ method at
> all.
But I have to initialize some default attributes. I could put them into
a method called something else, but that would have the same problem.
The question I put up is not specific to constructors, initializers or
whatever. It was a general question about super() being used in a
hierarchy with different signatures of the same method. I'm not sure why
everybody started to discuss __init__ and __new__ :-)

> Raymond Hettinger gives an excellent presentation where he describes various
> problems with MI and gives solutions for them. I think this might be it:
>
> http://pyvideo.org/video/1094/the-art-of-subclassing-0
I'm going to get back when I'm done with this video.  It will take some
hours. :-)

>> There is a single class (Widget) that has changed the signature of the
>> constructor. 
> Is this your code? Then simply fix Widget. MI in Python is cooperative: all
> the classes have to be designed for MI. It seems that Widget is not.
> (Possibly I have misdiagnosed the problem, and the fault lies elsewhere.)
If I knew what would be a good fix, I would do it. Somebody else
suggested to always use *args and **kwargs. That would be cooperative
for sure. But then It would be much harder to document the code (with
Sphinx for example), or use the syntax analyzer of an IDE (say PyCharm)
and have code completion. (Although the later is not a good argument
against the language itself.)
> Even if you got your wish, you couldn't use it until you're using Python 3.6
> or higher.
Yes, I know. I do this for fun, not for money.
> That's overly strict. As Raymond shows, it is easy to deal with
> changing method signatures in *cooperative* classes. 
I must watch that for sure.
> Perhaps you are unaware that manually calling the superclass method does not
> work correctly in cases of multiple inheritance? You end up either missing
> classes, and not calling their method, or calling them twice. That's why
> you need to use a proper linearisation algorithm, as used by super.
>
> See this explanation of C3 linearisation here:
>
> https://www.python.org/download/releases/2.3/mro/
I do not use diamond shapes in my hierarchy, I guess that does not
affect me. I may be wrong.

Thank you!

   Laszlo


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

Re: Multiple inheritance, super() and changing signature

[Ben Finney]

Nagy László Zsolt  writes:

> > [...] 
> >> class BootstrapDesktop(BootstrapWidget, BaseDesktop):
> >> def __init__(self, appserver, session):
> >> # there is NOTHING else here, it just connects bootstrap widget
> >> implementation with desktop methods
> >> super(BootstrapDesktop, self).__init__(appserver, session)
> > The correct way to do that is to simply not define an __init__ method at
> > all.
> But I have to initialize some default attributes.

Then the statement “there is NOTHING else here” must be false. Either
the custom ‘__init__’ does something useful, or it doesn't.

> > See this explanation of C3 linearisation here:
> >
> > https://www.python.org/download/releases/2.3/mro/
> I do not use diamond shapes in my hierarchy, I guess that does not
> affect me. I may be wrong.

With classes all inheriting ultimately from ‘object’ (as all Python 3
classes do, and as all current Python 2 classes should), mutliple
inheritance inevitably places your classes in a diamond inheritance
pattern. And, what's more, you can't know when writing a class whether
it participates in a multiple inheritance hierarchy!

So in practice you must write every class so that it will behave well in
a diamond inheritance pattern.

All this is covered in Raymond Hettinger's material, so it's best that I
just leave you to read that.

-- 
 \“If the arguments in favor of atheism upset you, explain why |
  `\they’re wrong. If you can’t do that, that’s your problem.” |
_o__) —Amanda Marcotte, 2015-02-13 |
Ben Finney

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

Re: Python on Windows with linux environment

[Eric S. Johansson]

On 6/3/2016 12:02 AM, Muhammad Ali wrote:
> On Friday, June 3, 2016 at 6:27:50 AM UTC+8, Eric S. Johansson wrote:
>> On 6/2/2016 2:03 PM, Joel Goldstick wrote:
>>> Although the OP is using Windows 7, according to recent articles,
>>> Ubuntu is teaming with MS for Windows 10 to include a bash shell,
>>> presumably with the package management of Ubuntu (debian), with pip
>>> goodness and virtualenv and virtualenvwrapper.  That route should make
>>> W10 and linux (ubuntu) nearly identical environments to deal with
>> had forgotten about that.  it should be released end of july and I am
>> looking forward to the update! in the meantime, I'm suffering with
>> cygwin :-)
>
> Please send me the link through which I can get regular updates about this 
> new release.

switch to windows 10 and wait.  MS will cram an update into your machine :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multiple inheritance, super() and changing signature

[Nagy László Zsolt]

> Raymond Hettinger gives an excellent presentation where he describes various
> problems with MI and gives solutions for them. I think this might be it:
>
> http://pyvideo.org/video/1094/the-art-of-subclassing-0
This is a much better version from one year later:

https://www.youtube.com/watch?v=miGolgp9xq8


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

Re: Multiple inheritance, super() and changing signature

[Steven D'Aprano]

On Fri, 3 Jun 2016 07:18 am, Random832 wrote:

> On Thu, Jun 2, 2016, at 13:36, Steven D'Aprano wrote:
[...]
>> But since the constructor/initialiser methods are so closely linked, many
>> people are satisfied to speak loosely and refer to "the constructor" as
>> either, unless they specifically wish to distinguish between __new__ and
>> __init__.
> 
> Where there is looseness, it comes from the fact that because __init__
> is always called even if __new__ returns a pre-existing object 

That's not quite correct. __init__ is not always called:

If __new__() does not return an instance of cls, then the new 
instance’s __init__() method will not be invoked.


https://docs.python.org/3/reference/datamodel.html#object.__new__


> people 
> often place code in __new__ which mutates the object to be returned,
> acting somewhat like a traditional constructor by assigning attributes
> etc.
> 
> But it is __init__ that acts like the thing that is called a constructor
> in many languages, and no-one's produced a single example of a language
> which uses "constructor" for something which allocates memory.

Yes you have: Python. Like it or not, it is common usage to call __new__ the
constructor and __init__ the initialiser. Even if the official docs are
agnostic on the issue, it is still widespread (but not universal) in the
Python community.

I have only come across two languages that split the "constructor" into two
methods, Objective C and Python. That does make Python rather special
compared to most other OO languages.

Objective C calls the part that allocates memory "alloc" (and is presumably
known as "the allocator") and the part which initialises it "init". "init"
is explicitly and officially known as the initialiser. Here's that link
again in case you missed it.

https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSObject_Class/index.html#//apple_ref/occ/instm/NSObject/init

Even if you dismiss Python, you can't dispute that the official Apple docs
for Cocoa refer to initialiser rather than constructor.


Python also follows that pattern of splitting the "constructor" into two:
__new__ and __init__. Until Python 2.2 introduced new-style classes, it was
common to refer to __init__ as the constructor. For instance, I have the
Python Pocket Reference from Python 1.5 which describes __init__ as:

Constructor: initialize the new instance, self.

When object and new-style classes were introduced, people wanted to
distinguish them. Since __new__ constructs the object, and __init__
initialises it (even in old-style classes __init__ is said to *initialise*
the instance), it seems natural to call __new__ the constructor and
__init__ the initialiser.

Perhaps we ought to have called them the allocator and the initialiser. If
you want to lead the push for that terminology, please be my guest.



-- 
Steven

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

Re: Multiple inheritance, super() and changing signature

[Nagy László Zsolt]

>> But I have to initialize some default attributes.
> Then the statement “there is NOTHING else here” must be false. Either
> the custom ‘__init__’ does something useful, or it doesn't.
Well... the custom __init__ method with nothing else just a super() call
was expressed there to show the super() call explicitly, and to
emphasize that in that particular class, super() is used instead of an
explicit base method call. It is not a pattern to be followed, just
syntactic sugar for the sake of the example.

So you are right: the custom __init__ in the  BootstrapDesktop class is
not really needed, and does not do anything useful in that particular
class.

My original statement was this: "I have to initialize some default
attributes", and for that I need to pass arguments. The truthness of
this statement is not affected by adding a useless override of a method
(with the very same parameters). Even though I see that you are right in
what you wrote, I think I don't understand the point because it seem
unrelated.

> All this is covered in Raymond Hettinger's material, so it's best that I
> just leave you to read that.
>
Is it available in written form? I have tried to watch the video, but
the sound quality is so poor that I cannot understand. I have tried to
search for a better one, but that is a different one. :-(


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

Re: Storing data in mysql

[mbg1708]

On Thursday, 2 June 2016 09:51:59 UTC+1, Anup reni  wrote:
> How to store this 3 dimensional data in Mysql database for plotting on map?
> ​

Actually, this looks like a question about the use of the SQL standard.

I really like Joe Celko's book "Instant SQL Programming".which provides 
LOTS of advice about portable SQLlikely across multiple SQL platforms.

and of course, both the question and my answer have nothing to do with 
Python or plotting or maps.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Don't put your software in the public domain

[Michael Torrie]

On Jun 3, 2016 04:57, "Steven D'Aprano"  wrote:
> (1) If the GPL licence is valid, then they are in breach of the licence
> terms, the licence is revoked, and they are not legally permitted to
> distribute or use the software;
>
> (2) If, as some people insist, the GPL licence is not valid, then they
have
> no valid licence, and are not legally permitted to distribute or use the
> software.
>
> That's why, for all the talk about the GPL never being held up in court,
> *nobody* has ever challenged it in court. If they did, and failed, then
> they would be in breach of copyright. If they succeeded, they would still
> be in breach of copyright. Any user of GPLed software who challenged it
> would be shooting themselves in the head: *either way*, win or lose, they
> would be in breach of copyright law.

I'm not sure this is completely right. The GPL explicitly says one doesn't
have to agree to the GPL to use the software. The GPL only comes into
affect when distribution is involved. So challenging the legitimacy of the
GPL in court (which certainly has happened in Germany) wouldn't prevent one
from using the GPL software. Only from distributing it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multiple inheritance, super() and changing signature

[Nagy László Zsolt]

>> That's overly strict. As Raymond shows, it is easy to deal with
>> changing method signatures in *cooperative* classes. 
> I must watch that for sure.

All right, I have read this:

https://rhettinger.wordpress.com/2011/05/26/super-considered-super/

There is still something I don't get: how to create cooperative classes
when some base classes share some of the parameters?

Here is an example modified from Raymond's post:

class A:
def __init__(self, param1, param2, **kwds):
self.param1 = param1
self.param2 = param2
super().__init__(**kwds)

class B:
def __init__(self, param1, param3, **kwds):
self.param1 = param1
self.param3 = param3
super().__init__(**kwds)


class X(A,B):
def __init__(self, param1, param2, param3, **kwds):
print("param1=",param1,"param2=",param2,"param3=",param3)
super().__init__(param1=param1,param2=param2,param3=param3,**kwds)

print(X.__mro__)
x = X(1,2,3)


Result:

(, , ,
)
param1= 1 param2= 2 param3= 3
Traceback (most recent call last):
  File "test.py", line 20, in 
x = X(1,2,3)
  File "test.py", line 17, in __init__
super().__init__(param1=param1,param2=param2,param3=param3,**kwds)
  File "test.py", line 5, in __init__
super().__init__(**kwds)
TypeError: __init__() missing 1 required positional argument: 'param1'

I could only find this as a solution:

class Root:
def __init__(self, **kwds):
pass

class A(Root):
def __init__(self, **kwds):
self.param1 = kwds['param1']
self.param2 = kwds['param2']
super().__init__(**kwds)

class B(Root):
def __init__(self, **kwds):
self.param1 = kwds['param1']
self.param3 = kwds['param3']
super().__init__(**kwds)


class X(A,B):
def __init__(self, param1, param2, param3, **kwds):
print("param1=",param1,"param2=",param2,"param3=",param3)
super().__init__(param1=param1,param2=param2,param3=param3,**kwds)

X(1,2,3)

But then self documentation and code completion becomes very problematic:

http://i.imgur.com/wzlh8uy.png


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

I'm wrong or Will we fix the ducks limp?

[Sayth Renshaw]

Very briefly because I hope to shot down eloquently.

Python is beautiful and is supposed to be a duck typed language, Yes?

Then if I create and assign to a new variable with a list action why does the 
duck not quack?

It feels wrong to spend a line writing what is already obvious

def getsMeet(files=file_list):
"""Get a File or List of Files.

From the list of files determine
what meetings exist and prepare them
to be parsed
"""
pyqFiles = []
for filename in sorted(file_list):
pyqFiles = pyqFiles.append(pq(filename=my_dir + filename))

return pyqFiles


Here I have to write that pyqFiles is a list before I take an explicit list 
action and append to it, if i create a variable and make it quack a list isn't 
it a list?

Assuming the answer is going to be that some methods apply to multiple types if 
not then what is happening?

Sayth

PS I am really having a lot of fun coding.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Recommendation for Object-Oriented systems to study

[Sayth Renshaw]

On Monday, 30 May 2016 00:42:17 UTC+10, Ankush Thakur  wrote:
> Hello,
> 
> I'm a self-taught programmer who has managed to claw his way out of Python 
> basics and even covered the intermediate parts. But I feel I have a ton of 
> theory in my head and would like to see some smallish applications in action. 
> More specifically, I'm looking for Object Oriented designs that will help me 
> cement my knowledge and expose me to best practices that books never cover. I 
> have half a mind to start reading up the Django or Pandas source code, but I 
> don't want to overwhelm myself. 
> 
> Can somebody recommend smaller and simpler projects I can learn from? And if 
> I can pick the brains of the creator, bonus points!
> 
> Thanks in advance!
> 
> Ankush

Hi Ankush

Can I refer you to a book, which isn't about object oriented design its 
actually about functional design, please wait though its one of the best books 
I am reading haven't made it to the end yet :-)

The author has written several books and about python object oriented design, 
but in writing about functional python it forces him to talk about when 
functional is good or bad and which parts of the language respond best to which 
approach, plus its clearly and straightforwardly written.

Its functional python programming by Steven Lott.

Cheers

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

Re: Multiple inheritance, super() and changing signature

[Ian Kelly]

On Fri, Jun 3, 2016 at 8:06 AM, Nagy László Zsolt  wrote:
>
>>> That's overly strict. As Raymond shows, it is easy to deal with
>>> changing method signatures in *cooperative* classes.
>> I must watch that for sure.
>
> All right, I have read this:
>
> https://rhettinger.wordpress.com/2011/05/26/super-considered-super/
>
> There is still something I don't get: how to create cooperative classes
> when some base classes share some of the parameters?

Why do they need to share the same parameter? Part of cooperative
design is that you can't really design each class in a vacuum; you
need to take the other classes they might get combined with into
account. Perhaps you can extract that parameter into another base
class that is shared by both:

class Root:
def __init__(self, *, param1, **kwds):
self.param1 = param1
super().__init__(**kwds)

class A(Root):
def __init__(self, *, param2, **kwds):
self.param2 = param2
super().__init__(**kwds)

class B(Root):
def __init__(self, *, param3, **kwds):
self.param3 = param3
super().__init__(**kwds)

class X(A, B):
pass

A and B can both depend on having param1 without stomping on each
other because they both inherit Root which requires it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Paul Rudin]

Sayth Renshaw  writes:

> Very briefly because I hope to shot down eloquently.
>
> Python is beautiful and is supposed to be a duck typed language, Yes?
>
> Then if I create and assign to a new variable with a list action why
> does the duck not quack?
>
> It feels wrong to spend a line writing what is already obvious
>

The problem is that you think that *variables* have a type. This isn't
the case. Objects have a type. A variable is a name by which you can
refer to an object. There are various ways in which you can associate a
object with a variable, the most obvious being an assignment statement.


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

Re: I'm wrong or Will we fix the ducks limp?

[Sayth Renshaw]

> The problem is that you think that *variables* have a type. This isn't
> the case. Objects have a type. A variable is a name by which you can
> refer to an object. There are various ways in which you can associate a
> object with a variable, the most obvious being an assignment statement.

So at the point I create the variable it refers to an object.

More correctly when I create the variable and assign a list action to the 
variable I believe I should be creating a reference to a list object in one 
motion; however python would like me to create the object first before creating 
a reference to it, is that the catch?

I am not allowed to create references to an object at the same time I create 
the object is that correct?

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

Re: Multiple inheritance, super() and changing signature

[Michael Selik]

On Fri, Jun 3, 2016 at 10:41 AM Ian Kelly  wrote:

> On Fri, Jun 3, 2016 at 8:06 AM, Nagy László Zsolt 
> wrote:
> > There is still something I don't get: how to create cooperative classes
> > when some base classes share some of the parameters?
>
> Why do they need to share the same parameter?
>

Is the problem that the attribute or parameter has the same name in both
base classes, but has different meanings in each?

If so, and you're in control of every class in the inheritance hierarchy,
perhaps you can come up with more specific names so that the bases no
longer share the same attribute.

If you can't change the base classes, I've got some other solutions, but
they're more involved, so I'll wait to hear back.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Ian Kelly]

On Fri, Jun 3, 2016 at 9:04 AM, Sayth Renshaw  wrote:
>
>
>> The problem is that you think that *variables* have a type. This isn't
>> the case. Objects have a type. A variable is a name by which you can
>> refer to an object. There are various ways in which you can associate a
>> object with a variable, the most obvious being an assignment statement.
>
> So at the point I create the variable it refers to an object.
>
> More correctly when I create the variable and assign a list action to the 
> variable I believe I should be creating a reference to a list object in one 
> motion; however python would like me to create the object first before 
> creating a reference to it, is that the catch?
>
> I am not allowed to create references to an object at the same time I create 
> the object is that correct?

I'd say leave references out of this. They don't correspond 1:1 with
variables, and bringing them up is only going to confuse the issue.

When you call the append method you're not "assigning a list action"
to the variable. You're just trying to call a method named "append".
That could be the list append method. Or it could be the array append
method. Or the deque append method. Or you may have written your own
class with an append method. How is the interpreter supposed to know
which one you mean?

In general, it can't, so it doesn't try. You have to create an object
before you can start doing anything it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Matt Wheeler]

Hi,

On Fri, 3 Jun 2016, 16:04 Sayth Renshaw,  wrote:

>
> So at the point I create the variable it refers to an object.
>

It's best to think of them as names, rather than variables, as names in
python don't behave quite how you'll expect variables to if you're coming
from some other languages.

More correctly when I create the variable and assign a list action to the
> variable I believe I should be creating a reference to a list object in one
> motion; however python would like me to create the object first before
> creating a reference to it, is that the catch?
>

I'm not 100% sure what you mean by "assign a list action to the variable".

`[]` is an empty list literal. Putting that in your code will create a new
empty list object every time it's reached.
`name =` assigns a new name which refers to the thing to the right of it.

My best guess as to the source of your confusion is that you're not seeing
the list as an object (let me know if I'm wrong).
A list is an object just the same as the items you want to put in it, it's
just a different type, it's not special syntax built into the language.
That means you need to create one if you want it to be there.

I am not allowed to create references to an object at the same time I
> create the object is that correct?
>

That's exactly what `name = []` is doing (see above).

> Assuming the answer is going to be that some methods apply to multiple
types if not then what is happening?
[from your first email]

If you want to see it like this that might help. Any number of classes and
not just the builtin list is likely to have an append method.
Even if that were not true, expecting name.append() in a context where name
doesn't exist to somehow magically create a list object for you, assign a
name to it and then call the method you asked for would involve quite a few
leaps of logic, faith or something.

Consider a situation where you actually intended to create an instance of a
different type which also has an `.append()` method, but somehow that went
wrong (you spelt the name incorrectly, perhaps), which is preferable:

Magic list creation mode:
>>> name = OtherClassWithAppendMethod()
>>> naem.append('this')
Great. Now we have our desired OtherClassWithAppendMethod instance, which
is empty, and a useless list which contains the stuff that should have been
given to `name`.
No errors, just a bug that's really really fun to track down.

Regular boring Python:
>>> name = OtherClassWithAppendMethod()
>>> naem.append('this')
NameError: name 'naem' is not defined

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

Re: I'm wrong or Will we fix the ducks limp?

[Sayth Renshaw]

That totally makes sense I was just double checking, had hoped I could create a 
variable assign it to a list and append in one stroke. 

Thanks 

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

Re: for / while else doesn't make sense

[Rob Gaddi]

Lawrence D’Oliveiro wrote:

> On Friday, June 3, 2016 at 8:09:21 AM UTC+12, Rob Gaddi wrote:
>> Although your loop is really the _canonical_ use case for
>> 
>> for loopvar in range(initial_value, limit+1):
>> processing
>> if found_what_im_looking_for:
>> break
>> else:
>> do_whatever_it_is_you_do_when_its_not_found
>
> The reason why I don’t like this is that there are two ways out of the Python 
> for-statement, and they are written quite differently. Why the asymmetry? 
> Logically, all ways out of a loop are of equal significance.

I wouldn't say that at all.  One is early termination due to success. 
The other is that you've run out of things to try, and exit due to
exhaustion of the iterator.  They're two very different cases, the same
as if I had wrapped the loop in a function:

def roundabout():
   for var in iterable:
   if successful(var): return var
   raise ValueError("Nothing works; all is lost")

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

Re: Multiple inheritance, super() and changing signature

[Nagy László Zsolt]

Is the problem that the attribute or parameter has the same name in both
base classes, but has different meanings in each?
If they had different meanings, a simple rename would solve the problem. 
They have the same meaning.



If you can't change the base classes, I've got some other solutions, but
they're more involved, so I'll wait to hear back.
One possible solution being encapsulating an object instead of 
inheriting from it?


Fortunately, I can change all of the classes, and extracting the common 
parameter into a common base class worked.


Problem solved. Thank you for all your help!

Cooperative classes are fantastic! :-)
--
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Michael Selik]

On Fri, Jun 3, 2016 at 11:58 AM Sayth Renshaw 
wrote:

> That totally makes sense I was just double checking, had hoped I could
> create a variable assign it to a list and append in one stroke.
>

In fact you can! It's called a "list comprehension"

pyqFiles = [pq(my_dir + filename) for filename in sorted(file_list)]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Peter Pearson]

On Fri, 3 Jun 2016 07:20:24 -0700 (PDT), Sayth Renshaw wrote:
[snip]
> pyqFiles = []
> for filename in sorted(file_list):
> pyqFiles = pyqFiles.append(pq(filename=my_dir + filename))
>
> return pyqFiles

[snip]
> PS I am really having a lot of fun coding.

To have even more fun, note that the above can be replaced by [untested]:

return [pq(filename=my_dir + filename)
for filename in sorted(file_list)]

(By the way, the "pf = pf.append(thing)" construction is weird.
All you need is pf.append(thing).)

-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Nagy László Zsolt]

def getsMeet(files=file_list):
 """Get a File or List of Files.

 From the list of files determine
 what meetings exist and prepare them
 to be parsed
 """
 pyqFiles = []
 for filename in sorted(file_list):
 pyqFiles = pyqFiles.append(pq(filename=my_dir + filename))

 return pyqFiles

This may not be the answer you are seeking, but how about:

def getsMeet(files=file_list):
return [pq(filename=my_dir + filename) for filename in sorted(file_list)]

If you can use any iterable instead of a list, then you can also 
consider using a generator:


def getsMeet(files=file_list):
for filename in sorted(file_list):
yield pq(filename=my_dir + filename)

for pg_obj in getsMeet(my_file_list):
process(pg_obj)

This way you do not need to construct a list at all, and it won't create all pq 
objects in advance.

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

Re: Recommendation for Object-Oriented systems to study

[Lawrence D’Oliveiro]

On Friday, June 3, 2016 at 9:12:19 PM UTC+12, Phuong Phan wrote:

> However, when I have chance to learn and work with other languages such as
> C# and C++. I found that they are also supercool.

Have you been exposed to Lisp yet?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Don't put your software in the public domain

[Lawrence D’Oliveiro]

On Friday, June 3, 2016 at 9:53:47 PM UTC+12, Steven D'Aprano wrote:

> A licence is something like a contract...

A licence is quite different from a contract. A contract requires some 
indication of explicit agreement by both parties, a licence does not. That’s 
why Free Software licences only have to say something like “by using this 
software, you agree to the following terms...”, because if the user doesn’t 
accept the licence, then they have no licence.

EULAs for proprietary software, on the other hand, try to have it both ways, by 
having a clause like the above, as well as requiring you to click an “I Agree” 
button or some such.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Friday, June 3, 2016 at 9:33:32 PM UTC+12, BartC wrote:
> On 03/06/2016 03:47, Lawrence D’Oliveiro wrote:
>> On Friday, June 3, 2016 at 8:52:52 AM UTC+12, BartC wrote:
>>> Simple iterative for-loops are more of a DIY effort...
>>
>> There is one case that Python handles more nicely than C.
> 
> Just one case? Python is miles away from a C 'for'.

Yes, just one case. In Python you write a loop with one exit in one way, a loop 
with two exits in a different way, and a loop with more than two exits in yet 
another entirely different way. Can you say “cognitive burden”?

The for-statement in C handles most of my looping requirements. I rarely use 
while-loops, and do-whiles almost not at all--not for looping, anyway
.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Saturday, June 4, 2016 at 3:52:42 AM UTC+12, Rob Gaddi wrote:
> Lawrence D’Oliveiro wrote:
> 
>> The reason why I don’t like this is that there are two ways out of the
>> Python for-statement, and they are written quite differently. Why the
>> asymmetry? Logically, all ways out of a loop are of equal significance.
> 
> I wouldn't say that at all.  One is early termination due to success. 
> The other is that you've run out of things to try, and exit due to
> exhaustion of the iterator.  They're two very different cases...

Different in what way? A loop exit is a loop exit. It causes termination of the 
loop.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multiple inheritance, super() and changing signature

[Michael Selik]

On Fri, Jun 3, 2016 at 12:01 PM Nagy László Zsolt 
wrote:

> > Is the problem that the attribute or parameter has the same name in
> both base classes, but has different meanings in each?
> If they had different meanings, a simple rename would solve the problem.
>

Sometimes finding a good name ain't so simple.

> If you can't change the base classes, I've got some other solutions, but
> > they're more involved, so I'll wait to hear back.
> One possible solution being encapsulating an object instead of
> inheriting from it?
>

That's one option, creating a wrapper class that dispatches almost
everything to the contained class, except with one renamed attribute/method.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Recommendation for Object-Oriented systems to study

[Ankush Thakur]

On Friday, June 3, 2016 at 7:54:55 PM UTC+5:30, Sayth Renshaw wrote:
> On Monday, 30 May 2016 00:42:17 UTC+10, Ankush Thakur  wrote:
> > Hello,
> > 
> > I'm a self-taught programmer who has managed to claw his way out of Python 
> > basics and even covered the intermediate parts. But I feel I have a ton of 
> > theory in my head and would like to see some smallish applications in 
> > action. More specifically, I'm looking for Object Oriented designs that 
> > will help me cement my knowledge and expose me to best practices that books 
> > never cover. I have half a mind to start reading up the Django or Pandas 
> > source code, but I don't want to overwhelm myself. 
> > 
> > Can somebody recommend smaller and simpler projects I can learn from? And 
> > if I can pick the brains of the creator, bonus points!
> > 
> > Thanks in advance!
> > 
> > Ankush
> 
> Hi Ankush
> 
> Can I refer you to a book, which isn't about object oriented design its 
> actually about functional design, please wait though its one of the best 
> books I am reading haven't made it to the end yet :-)
> 
> The author has written several books and about python object oriented design, 
> but in writing about functional python it forces him to talk about when 
> functional is good or bad and which parts of the language respond best to 
> which approach, plus its clearly and straightforwardly written.
> 
> Its functional python programming by Steven Lott.
> 
> Cheers
> 
> Sayth

Thanks, Sayth. Functional programming is indeed a very interesting paradigm, 
but I hear that Python's functional paradigms are cramped at best. I will learn 
a pure functional language later, but for now I'm looking for good old objects.

Best,
Ankush
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Recommendation for Object-Oriented systems to study

[Ankush Thakur]

On Wednesday, June 1, 2016 at 2:53:22 PM UTC+5:30, Terry Reedy wrote:
> On 5/31/2016 1:52 PM, Ankush Thakur wrote:
> > Hi Terry,
> >
> > Can you point me towards the source code?
> 
> For IDLE 3.4.4 or 3.5.1: /Lib/idlelib/help.py, at least on 
> Windows.
> 
>  > by "after reading it carefully", do you mean you or me? :D
> 
> You.  I wrote it and already read it carefully.
> 
> >> Beyond "pick a module with classes that interest you", I can suggest
> >> idlelib.help, which I helped to write.  If you ask, after reading it
> >> carefully, I will point out what I consider positive features.
> 
> -- 
> Terry Jan Reedy

All right, it's a deal! Here's a link I found: 
https://github.com/python/cpython/blob/master/Lib/idlelib/help.py. Can I write 
to you with questions I might have? :)

Best,
Ankush
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Q] ImportError by __import__() on Python >= 3.4

[MRAB]

On 2016-06-03 06:48, Makoto Kuwata wrote:
On Fri, Jun 3, 2016 at 9:31 AM, MRAB > wrote:


On 2016-06-02 15:04, Makoto Kuwata wrote:

Hi,

I have a trouble around __import__().
The following sample code works well on Python <= 3.3,
but it raises ImportError on Python >= 3.4.


## importtest.py
import sys, os, shutil

def test(name):
try:
## create 'foo/__init__.py' file
os.mkdir(name)
with open(name + "/__init__.py", 'w') as f:
f.write("X=1")
f.flush()
## ipmort 'foo' module
mod = __import__(name)
finally:
if os.path.isdir(name):
shutil.rmtree(name)

test("foo")# no errors
test("bar")# may raise error on Python >= 3.4. Why?


Output Example:

### No errors  (Python <= 3.3)
ubuntu$ export PYTHONPATH=.
ubuntu$ for x in 1 2 3 ; do /usr/bin/python3.3
importtest.py; done

### ImportError (Python >= 3.4)
ubuntu$ export PYTHONPATH=.
ubuntu$ for x in 1 2 3 ; do /usr/bin/python3.4
importtest.py; done
Traceback (most recent call last):
  File "tmp/importtest.py", line 19, in 
test("bar")# may raise error on Python >= 3.4. Why?
  File "tmp/importtest.py", line 13, in test
mod = __import__(name)
ImportError: No module named 'bar'


Please give me any advices or hints.
Thanks.

Things to try:

Does the order matter? If you try "bar" then "foo" does "foo" fail?


Yes. Name is not matter. Order is matter.


Does the directory matter?


No. I created "foo" and "bar" directories in order to create python 
module.



Is there something called "bar" in the directory already?


No. Sample script removes directories every time.


What does the created "bar" directory contain? Does it really
contain only "__init__.py"?


Yes. See sample script for detail.

You're testing the script 3 times; on which iteration does it fail?


Because sometimes script will fail and sometimes will work file.

It sounds like it's some kind of race condition, e.g. it hasn't finished 
writing the file before it does the import.


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

Re: Multiple inheritance, super() and changing signature

[Ben Finney]

Nagy László Zsolt  writes:

> So you are right: the custom __init__ in the BootstrapDesktop class is
> not really needed, and does not do anything useful in that particular
> class.

I disagree: setting initial attributes is a normal and useful case for
defining a custom initialiser.

> My original statement was this: "I have to initialize some default
> attributes", and for that I need to pass arguments.

Yes. If you need to initialise the instance, that's what a custom
‘__init__’ is for.

> The truthness of this statement is not affected by adding a useless
> override of a method (with the very same parameters). Even though I
> see that you are right in what you wrote, I think I don't understand
> the point because it seem unrelated.

My point was rather that if the custom initialiser does *nothing* except
call the superclass's initialiser, then there's no purpose to writing
the custom initialiser.


If you're writing a custom initialiser that handles two additional
parameters, then those parameters should not be present when you call
the super() method's initialiser::

# You specified Python 3, which allows simpler syntax.

class LoremIpsum:
def __init__(self, spam, *args, **kwargs):
do_something_important_with(spam)
super().__init__(*args, **kwargs)

class DolorSitAmet(LoremIpsum):
def __init__(self, spam, eggs=4, beans=None, *args, **kwargs):
self.eggs = eggs
self.beans = beans
super().__init__(spam, *args, **kwargs)

So the sub-class follows the Liskov Substitution Principle: every
DolorSitAmet instance should be substitutable for LoremIpsum instances,
and users that only expect a LoremIpsum instance should not need to know
any difference.

This entails that its methods (in this case the initialiser) will accept
the same parameters as ‘LoremIpsum.__init__’, and do the same things
with those parameters. We make that explicit by omitting the
*additional* parameters that we already handled, ‘eggs’ and ‘beans’,
from the next call in the chain.

-- 
 \“The difference between religions and cults is determined by |
  `\  how much real estate is owned.” —Frank Zappa |
_o__)  |
Ben Finney

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

Re: Multiple inheritance, super() and changing signature

[Ben Finney]

Nagy László Zsolt  writes:

> Fortunately, I can change all of the classes, and extracting the
> common parameter into a common base class worked.

This is why Liskov's Substitution Principle is good: Thinking of it as a
law helps lead to better design.

In this case, the same parameter doing different things in different
sub-classes meant that instances of those sub-classes had difficulty
substituting for the superclass. Interrogating the design against the
LSP reveals that.

> Problem solved. Thank you for all your help!
> Cooperative classes are fantastic! :-)

I'm glad you discovered them :-)

-- 
 \   “Truth is stranger than fiction, but it is because fiction is |
  `\ obliged to stick to possibilities, truth isn't.” —Mark Twain, |
_o__)  _Following the Equator_ |
Ben Finney

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

Re: Don't put your software in the public domain

[Nobody]

On Fri, 03 Jun 2016 09:15:55 -0700, Lawrence D’Oliveiro wrote:

>> [quoted text muted]
> 
> A licence is quite different from a contract. A contract requires some
> indication of explicit agreement by both parties, a licence does not.

More precisely, it requires "mutual consideration", i.e. each party must
provide something of value to the other. If a party doesn't provide
something of value, they can't claim any harm in the event of a breach, as
they haven't lost anything (failure to receive what the other party
promised doesn't count, as it didn't belong to the recipient to start with).

This is why you sometimes see contracts where one party pays a nominal sum
(e.g. one pound/dollar/euro) in return for assets which may have
significant value but also significant liabilities attached. The fact that
they paid /something/ allows them to enforce the contract.

OTOH, a Free software licence is unilateral; the author grants the user
certain rights, with the user providing nothing in return.

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

Re: Multiple inheritance, super() and changing signature

[Ian Kelly]

On Fri, Jun 3, 2016 at 2:16 PM, Ben Finney  wrote:
> If you're writing a custom initialiser that handles two additional
> parameters, then those parameters should not be present when you call
> the super() method's initialiser::
>
> # You specified Python 3, which allows simpler syntax.
>
> class LoremIpsum:
> def __init__(self, spam, *args, **kwargs):
> do_something_important_with(spam)
> super().__init__(*args, **kwargs)
>
> class DolorSitAmet(LoremIpsum):
> def __init__(self, spam, eggs=4, beans=None, *args, **kwargs):
> self.eggs = eggs
> self.beans = beans
> super().__init__(spam, *args, **kwargs)

Except that since we're discussing design for multiple inheritance,
the positional argument "spam" is inappropriate. All arguments should
be passed by keyword; the DolorSitAmet.__init__ method cannot be
certain that LoremIpsum will be the next class in the MRO, and the
actual next class might not expect spam to be the first positional
argument.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Sayth Renshaw]

On Saturday, 4 June 2016 02:04:43 UTC+10, Michael Selik  wrote:

> 
> > That totally makes sense I was just double checking, had hoped I could
> > create a variable assign it to a list and append in one stroke.
> >
> 
> In fact you can! It's called a "list comprehension"
> 
> pyqFiles = [pq(my_dir + filename) for filename in sorted(file_list)]

Actually thats where I was coming from I can create a list with a list 
comprehension in one go, but I cant create a list with an append method 
pf.append(thing) in one go .

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

Re: I'm wrong or Will we fix the ducks limp?

[Sayth Renshaw]

> > pyqFiles = []
> > for filename in sorted(file_list):
> > pyqFiles = pyqFiles.append(pq(filename=my_dir + filename))
> >
> > return pyqFiles
> 
> [snip]
> > PS I am really having a lot of fun coding.
> 
> To have even more fun, note that the above can be replaced by [untested]:
> 
> return [pq(filename=my_dir + filename)
> for filename in sorted(file_list)]
> 
> (By the way, the "pf = pf.append(thing)" construction is weird.
> All you need is pf.append(thing).)
> 
> -- 
>

I got the pf = pf.append(thing) from doing pandas because in pandas its not an 
inplace function.

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

Catch exception with message?

[Piyush Verma]

Generally we catch exception using
except Exception as e:

But sometimes, we see same type of exception is present with different
message.Is there a way to capture same exception with message
filtering? Please help me to do this.

Regards,
~Piyush
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Sayth Renshaw]

> > def getsMeet(files=file_list):
> >  """Get a File or List of Files.
> >
> >  From the list of files determine
> >  what meetings exist and prepare them
> >  to be parsed
> >  """
> >  pyqFiles = []
> >  for filename in sorted(file_list):
> >  pyqFiles = pyqFiles.append(pq(filename=my_dir + filename))
> >
> >  return pyqFiles
> This may not be the answer you are seeking, but how about:
> 
> def getsMeet(files=file_list):
>  return [pq(filename=my_dir + filename) for filename in sorted(file_list)]
> 
> If you can use any iterable instead of a list, then you can also 
> consider using a generator:
> 
> def getsMeet(files=file_list):
>  for filename in sorted(file_list):
>  yield pq(filename=my_dir + filename)
> 
> for pg_obj in getsMeet(my_file_list):
>  process(pg_obj)
> 
> This way you do not need to construct a list at all, and it won't create all 
> pq objects in advance.

Ok now that is cool and definitely I need to play with that a little more.

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

Re: Catch exception with message?

[Ian Kelly]

try:
something
except Exception as e:
if e.args[0] == message_of_interest:
handle_it
else:
raise

On Fri, Jun 3, 2016 at 5:14 PM, Piyush Verma <114piy...@gmail.com> wrote:
> Generally we catch exception using
> except Exception as e:
>
> But sometimes, we see same type of exception is present with different
> message.Is there a way to capture same exception with message
> filtering? Please help me to do this.
>
> Regards,
> ~Piyush
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Catch exception with message?

[Random832]

On Fri, Jun 3, 2016, at 19:14, Piyush Verma wrote:
> Generally we catch exception using
> except Exception as e:
> 
> But sometimes, we see same type of exception is present with different
> message.Is there a way to capture same exception with message
> filtering? Please help me to do this.

The message is meant to be human-readable, and may change without
warning. Is there no other property on the exceptions you want to catch
that can be used to distinguish them? (errno, perhaps?) What's your
specific use case?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multiple inheritance, super() and changing signature

[Ben Finney]

Ian Kelly  writes:

> Except that since we're discussing design for multiple inheritance,
> the positional argument "spam" is inappropriate. All arguments should
> be passed by keyword; the DolorSitAmet.__init__ method cannot be
> certain that LoremIpsum will be the next class in the MRO, and the
> actual next class might not expect spam to be the first positional
> argument.

You're right. That also allows us to stop handling unknown positional
arguments.

This does make it troublesome to design the function signature though,
and I can see why people balk at how to deal with the semantics of
‘super’ in Python 2::

class LoremIpsum(object):
def __init__(self, **kwargs):
spam = kwargs.pop('spam')
do_something_important_with(spam)
super(LoremIpsum, self).__init__(**kwargs)

class DolorSitAmet(LoremIpsum):
def __init__(self, **kwargs):
self.eggs = kwargs.pop('eggs')
self.beans = kwargs.pop('beans')
super(DolorSitAmet, self).__init__(**kwargs)

That's awful :-( because the initialiser's signature no longer shows any
sign of which parameters matter for this class.

It also sucks to need ‘dict.pop('name')’, instead of just ‘name’.


Keyword-only parameters make this easier and clearer::

class LoremIpsum:
def __init__(self, *, spam, **kwargs):
spam = kwargs.pop('spam')
do_something_important_with(spam)
super().__init__(**kwargs)

class DolorSitAmet(LoremIpsum):
def __init__(self, *, eggs=4, beans=None, **kwargs):
self.eggs = eggs
self.beans = beans
super().__init__(**kwargs)

I guess that's yet another reason to advocate Python 3 for all new code.

-- 
 \  “One time a cop pulled me over for running a stop sign. He |
  `\said, ‘Didn't you see the stop sign?’ I said, ‘Yeah, but I |
_o__)don't believe everything I read.’” —Steven Wright |
Ben Finney

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

Re: Catch exception with message?

[Ben Finney]

Piyush Verma <114piy...@gmail.com> writes:

> But sometimes, we see same type of exception is present with different
> message.Is there a way to capture same exception with message
> filtering? Please help me to do this.

That's a nasty code smell. Why would you want your code to behave
differently depending on what the text of the message is? The message
should not change the semantic meaning of the exception type.

If there are exceptions that *mean* different things (i.e. that require
different handling), they should be different types.

See the Python 3 standard exception hierarchy for a good example.

-- 
 \“The greatest tragedy in mankind's entire history may be the |
  `\   hijacking of morality by religion.” —Arthur C. Clarke, 1991 |
_o__)  |
Ben Finney

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

Re: Multiple inheritance, super() and changing signature

[Gregory Ewing]

Nagy László Zsolt wrote:

I do not use diamond shapes in my hierarchy, I guess that does not
affect me. I may be wrong.


If there are no diamonds, there is no need to use super.
Explicit inherited method calls, done correctly, will
work fine.

The only downside is that if your inheritance hierarchy
changes, you need to review all your inherited calls
to make sure they're still correct.

The use of super to address that issue seems attractive.
However, super is only applicable if some rather stringent
requirements are met:

1. All the methods must have compatible signatures.

2. Except for 3 below, all classes participating in the
hierarchy must use super for a given method if any of
them do, including any future subclasses.

3. There must be a class at the top of the hierarchy
that does *not* make super calls, to terminate the chain.

4. It must not matter what order the methods in a super
chain are called. This is because you cannot predict
which method a given super call will invoke. It could
belong to a subclass of the class making the call.

If you can't satisfy *all* of these reqirements, then
you can't use super. Sorry, but that's just the way
super is.

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

Re: Don't put your software in the public domain

[Lawrence D’Oliveiro]

On Saturday, June 4, 2016 at 8:58:19 AM UTC+12, Nobody wrote:
> On Fri, 03 Jun 2016 09:15:55 -0700, Lawrence D’Oliveiro wrote:
> 
> >> [quoted text muted]
> > 
> > A licence is quite different from a contract. A contract requires some
> > indication of explicit agreement by both parties, a licence does not.
> 
> More precisely, it requires "mutual consideration", i.e. each party must
> provide something of value to the other. If a party doesn't provide
> something of value, they can't claim any harm in the event of a breach, as
> they haven't lost anything (failure to receive what the other party
> promised doesn't count, as it didn't belong to the recipient to start with).

Thanks for clarifying that.

> This is why you sometimes see contracts where one party pays a nominal sum
> (e.g. one pound/dollar/euro) in return for assets which may have
> significant value but also significant liabilities attached. The fact that
> they paid /something/ allows them to enforce the contract.

I wonder about the point of that, though; I have heard of cases where the judge 
ruled that the contract had been breached, and awarded damages of one 
pound/dollar/euro. So other than winning a symbolic victory, what was the point?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Catch exception with message?

[cs]

On 04Jun2016 04:44, Piyush Verma <114piy...@gmail.com> wrote:

Generally we catch exception using
except Exception as e:

But sometimes, we see same type of exception is present with different
message.Is there a way to capture same exception with message
filtering? Please help me to do this.


Quick note: you almost never was to catch "Exception", you almost always want 
to catch a particular Exception subtype such as ValueError.


Regarding your questuon: sure. Just examine the message. For example:

 try:
   ...
 except SomeException as e:
   if e.message == 'some specific string':
 ... handle that ...
   elif e.message.startswith('some prefix'):
 ... handle that ...
   elif ...
 ...
   else:
 # exception _not_ handled, reraise it for someone further out
 # to handle correctly
 raise

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Multiple inheritance, super() and changing signature

[Gregory Ewing]

Ben Finney wrote:

With classes all inheriting ultimately from ‘object’ (as all Python 3
classes do, and as all current Python 2 classes should), mutliple
inheritance inevitably places your classes in a diamond inheritance
pattern.


That's usually harmless, though, because object provides
very little functionality of its own.

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

Re: Don't put your software in the public domain

[Steven D'Aprano]

On Fri, 3 Jun 2016 11:14 pm, Michael Torrie wrote:

> I'm not sure this is completely right. The GPL explicitly says one doesn't
> have to agree to the GPL to use the software. The GPL only comes into
> affect when distribution is involved. 

Yes, you're right, I was unclear. 

See https://opensource.org/licenses/GPL-2.0

in particular clause 5. The GNU Library General Public License will be
similar.

I was thinking about the difference between a user of the software (as in
programmers and developers) versus *end-users* of the software who merely
use the finished product, but neglected to make that explicit. Sorry about
that.

Mere use of the code as an end-user does not require that you make the
source code available: the GPL states "The act of running the Program is
not restricted", which is blanket permission (a licence?) to run the GPLed
code.

(I am surprised that it takes so little to grant end-user usage rights, but
IANAL and presumably the FSF's lawyers consider that sufficient. Perhaps
there are common law usage rights involved.)

I intended to refer to users of the GPL software as developers, that is,
those who incorporate The Program (the GPLed code) in their own code. For
those people, you need a licence to copy, distribute and modify the GPLed
code. And *that* comes with restrictions: if you distribute the copied or
modified code, then you must abide by the terms of the GPL, which is to
give *your* users the same licence as the GPL offers.

If you don't, then you have no right to copy, distribute or modify the code,
and are in breach of copyright.


> So challenging the legitimacy of the 
> GPL in court (which certainly has happened in Germany) wouldn't prevent
> one from using the GPL software. Only from distributing it.


Are you referring to Welte vs Sitecom? I wasn't aware of that until now.

If so, this case found that the GPL was valid, and enforced the terms of the
GPL against Sitecom.

There have been many times that the Software Freedom Law Center (SFLC) has
had to force companies to comply with the GPL. There has been at least one
time that they actually had to take legal action to force compliance
(against Monsoon Multimedia, Inc, on behalf of Busybox). Normally
infringers back down when caught, but Monsoon dug their heels in and
refused to budge. So the SFLC took them to court.

Not surprisingly, Monsoon settled out of court rather than risk a bigger
penalty from a judge. As the SFLC Legal Director Daniel B. Ravicher said:

In all of our years of doing open source license enforcement 
work, we’ve never come across any party that thought it was 
in their best interest to test the GPL in court, and Monsoon 
was no exception.

http://torquemag.io/2013/03/busybox/

They preferred to pay a financial settlement (in other words, a fine) and
come into compliance, rather than risk having a judge tell them they were
infringing copyright.



-- 
Steven

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

Re: I'm wrong or Will we fix the ducks limp?

[Terry Reedy]

On 6/3/2016 10:20 AM, Sayth Renshaw wrote:

Very briefly because I hope to shot down eloquently.

Python is beautiful and is supposed to be a duck typed language, Yes?

Then if I create and assign to a new variable with a list action why does the 
duck not quack?

It feels wrong to spend a line writing what is already obvious

def getsMeet(files=file_list):
"""Get a File or List of Files.

From the list of files determine
what meetings exist and prepare them
to be parsed
"""
pyqFiles = []
for filename in sorted(file_list):


The parameter name if files, not file_list.  The latter is just the default.


pyqFiles = pyqFiles.append(pq(filename=my_dir + filename))

return pyqFiles


You can replace the body with

return [pq(filename=my_dir+filename) for filename in sorted(files)]

where files is any iterable of file names.

--
Terry Jan Reedy

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

Re: Don't put your software in the public domain

[Steven D'Aprano]

On Sat, 4 Jun 2016 02:15 am, Lawrence D’Oliveiro wrote:

> On Friday, June 3, 2016 at 9:53:47 PM UTC+12, Steven D'Aprano wrote:
> 
>> A licence is something like a contract...
> 
> A licence is quite different from a contract. A contract requires some
> indication of explicit agreement by both parties, a licence does not.

That's a very good point. In the USA:

A license is a unilateral abrogation of rights. The licensor has,
by law, the ability to enforce certain rights against the licensee,
and the license functions as a promise not to enforce those rights.
[...] if the conditions are violated, which essentially makes it a
contract. As further discussed below, a contract requires mutual
agreement and bilateral consideration. It is likely that a court,
in the U.S. or abroad, would recognize the GPL as a contract.

And further:

There must be an offer, acceptance of that offer, and something of
value exchanged.

"Taking the case: Is the GPL enforceable?", Jason B Wacha, Santa Clara High
Technology Law Journal, Vol. 21 Issue 2.

http://digitalcommons.law.scu.edu/cgi/viewcontent.cgi?article=1380&context=chtlj


In the case of the GPL, the offer is the right to copy, distribute and
modify the software, acceptance is the act of copying, distributing or
modifying the software. The exchange does not have to be monetary. In
exchange for the right to copy, distribute and modify the software, the
licensee agrees to keep copyright notices intact, insert certain required
notices, and redistribute the code only under the conditions of the
license. This is sufficient consideration, at least under US contract law.

In Europe and particularly Germany, things are different, as the German
courts don't recognise licences as a thing[1]. The GPL would have to be
treated as a contract, or not be legally meaningful. But that doesn't hurt
the GPL: if it is found to be invalid, then the infringing licensee finds
themselves with only their limited rights under copyright law, which most
certainly does not include the right to make unlimited copies and
distribute them.

As Wacha writes in the same paper:

But what if, for some reason, a court held the GPL to be an 
unenforceable license? [...] the licensee (who received the 
code) reverts back to her common law rights. That means that 
she has the rights to use the program (i.e., to copy into
memory as necessary to run it) and to make a backup copy. 
What disappears are the restrictions and other limitations 
in the GPL. But these will be the only rights a licensee 
has-she would have no right to distribute, and no right to 
modify. So for a user, challenging the validity of the GPL 
is a dangerous game.



> That’s why Free Software licences only have to say something like “by
> using this software, you agree to the following terms...”, because if the
> user doesn’t accept the licence, then they have no licence.

Right.


> EULAs for proprietary software, on the other hand, try to have it both
> ways, by having a clause like the above, as well as requiring you to click
> an “I Agree” button or some such.

I have no comment on whether or not that makes EULA a contract, or whether
it is relevant to the discussion. Wacha has some things to say
about "clickwrap licences", see the URL above.



-- 
Steven

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

Re: for / while else doesn't make sense

[Steven D'Aprano]

On Sat, 4 Jun 2016 02:22 am, Lawrence D’Oliveiro wrote:

> In Python you write a loop with one exit in one way, a loop with two exits
> in a different way, and a loop with more than two exits in yet another
> entirely different way. Can you say “cognitive burden”?

Yes I can, but I don't see the point.

In Python, you write a loop with one exit one way:

for x in seq:
do_something()


and a loop with two or more exits a *trivially different* way:

for x in seq:
do_something()
if condition:
break
if another_condition:
break


You can put as many or as few break statements in the loop as you like,
whether it is zero or one or ten or a thousand, the for-loop is written the
same way, with a slight difference only when going from the "no early exit"
case to "at least one early exit" case. How is this a cognitive burden?

Programming is about composing code from smaller components in this way.
Here is how you add two numbers:

result = a + b

and three numbers:

result = a + b + c

and four numbers:

result = a + b + c + d

This isn't three or more different ways to add numbers, depending on how
many numbers you have to add. It is ONE way to add, composed as many times
as you need it. For-loops are no different: you can exit the loop by
reaching the end and exiting, or you can exit early by using break. The
number of breaks is just composition.




-- 
Steven

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

Re: Don't put your software in the public domain

[Steven D'Aprano]

On Sat, 4 Jun 2016 06:58 am, Nobody wrote:

> OTOH, a Free software licence is unilateral; the author grants the user
> certain rights, with the user providing nothing in return.

That's not the case with the GPL.

The GPL requires the user (not the end-user, who merely avails themselves of
their common law right to run the software, but the developer user, who
copies, distributes and modifies the code) to do certain things in return
for the right to copy, distribute and modify the code:

- you must forgo your right to keep your derived work a trade secret;

- you must keep copyright licences intact;

- you must attach certain notices (the GPL itself);

- you must make the source code to your derived work available to your
users, in certain ways (e.g. distributed together with the application) but
not others (locked in a filing cabinet at the bottom of a disused mineshaft
in Patagonia).

The courts in Germany have already found that the GPL satisfies the
conditions to be considered a contract; it is likely that so would US
courts.




-- 
Steven

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

Re: I'm wrong or Will we fix the ducks limp?

[Steven D'Aprano]

On Sat, 4 Jun 2016 09:06 am, Sayth Renshaw wrote:

> I cant create a list with an append method pf.append(thing) in one go .

Correct. You cannot append to a list until the list exists.

Nor can you uppercase a string until the string exists:

s = "hello world"
s = s.uppercase()


Nor can you add one to a number until the number exists.

x = 0
x += 1


Why should lists be different? How is Python supposed to know pf is a list
with an append method if pf doesn't exist?

# pf = []
pf.append(thing)



-- 
Steven

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

Re: Catch exception with message?

[Steven D'Aprano]

On Sat, 4 Jun 2016 09:14 am, Piyush Verma wrote:

> Generally we catch exception using
> except Exception as e:
> 
> But sometimes, we see same type of exception is present with different
> message.

That suggests that whoever wrote the code doesn't know what they're doing.
Intentionally giving the same error message for different exception types
is poor design.


> Is there a way to capture same exception with message 
> filtering? Please help me to do this.

Error messages are not part of the public API of Python's built-ins and
standard library. That means that error messages are subject to change at
any time, without warning. There is no backwards compatibility requirement
for the error message to stay the same.

In principle that means that the same function might use a different error
message each time you run it. But in practice, it means that even bug-fix
releases of Python can change error messages.

So don't do this, it is a terrible idea. You should never rely on the error
message of an exception.

But if you insist:

try:
something()
except Exception as e:
if e.args[0] = "An error occurred":
print("could you be any less specific?")



-- 
Steven

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

Re: Multiple inheritance, super() and changing signature

[Steven D'Aprano]

On Sat, 4 Jun 2016 11:06 am, Gregory Ewing wrote:

> Nagy László Zsolt wrote:
>> I do not use diamond shapes in my hierarchy, I guess that does not
>> affect me. I may be wrong.
> 
> If there are no diamonds, 

In Python 3, or Python 2 with new-style classes, there are ALWAYS diamonds
when you use multiple inheritance.


> there is no need to use super. 

Except then you are precluding others from integrating your classes into
their class hierarchies.


> Explicit inherited method calls, done correctly, will
> work fine.
> 
> The only downside is that if your inheritance hierarchy
> changes, you need to review all your inherited calls
> to make sure they're still correct.
> 
> The use of super to address that issue seems attractive.
> However, super is only applicable if some rather stringent
> requirements are met:
> 
> 1. All the methods must have compatible signatures.
> 
> 2. Except for 3 below, all classes participating in the
> hierarchy must use super for a given method if any of
> them do, including any future subclasses.
> 
> 3. There must be a class at the top of the hierarchy
> that does *not* make super calls, to terminate the chain.

Normally that will be object.

Sometimes you need to prevent messages reaching object. But to my mind,
that's a code-smell, and indicates you're doing something wrong.

"Something wrong" may be multiple inheritance itself. There is a reason why
most languages don't allow MI at all, or only allow a much restricted
subset of it, in the form of mixins or traits.

And in fact, even using inheritance alone is harder than it seems.
Composition is just as powerful and usually easier to work with.

[...]

> If you can't satisfy *all* of these reqirements, then
> you can't use super. Sorry, but that's just the way
> super is.

If you can't use super, then chances are you can't use *anything*, including
manual calls to superclass methods. There's nothing magical about the use
of super itself. If you have problems with super, then you have two
choices:

(1) Manually walk the MRO making the same calls that super would have made,
in which case you'll have the same problems super did.

(2) DON'T walk the MRO making the same calls that super would have made, in
which case you will have all the problems that super solves. Namely, you
will either miss calling superclass methods, or you will call them two many
times.


In a straight linear single inheritance class hierarchy, walking the MRO is
trivial whether you use super or not, but not using super restricts you to
never using super. But in MI, not using super almost certainly means you're
doing it wrong.

(If you're lucky, you can get away with it if the methods you fail to call
aren't needed, or do nothing, and the methods you call twice are harmless.)




-- 
Steven

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

Re: for / while else doesn't make sense

[Steven D'Aprano]

On Sat, 4 Jun 2016 02:24 am, Lawrence D’Oliveiro wrote:

> On Saturday, June 4, 2016 at 3:52:42 AM UTC+12, Rob Gaddi wrote:
>> Lawrence D’Oliveiro wrote:
>> 
>>> The reason why I don’t like this is that there are two ways out of the
>>> Python for-statement, and they are written quite differently. Why the
>>> asymmetry? Logically, all ways out of a loop are of equal significance.
>> 
>> I wouldn't say that at all.  One is early termination due to success.
>> The other is that you've run out of things to try, and exit due to
>> exhaustion of the iterator.  They're two very different cases...
> 
> Different in what way? A loop exit is a loop exit. It causes termination
> of the loop.

You can exit a loop because you have run out of items to process, or you can
exit the loop because a certain condition has been met.

The canonical example is a search, where you need to process differently
depending on whether a match was found or not. In pseudo-code:


for item in items:
if condition(item):
# found match, exit loop
break

if match was found:
process match
else:
no match



-- 
Steven

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

Re: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Saturday, June 4, 2016 at 2:22:18 PM UTC+12, Steven D'Aprano wrote:
> and a loop with two or more exits a *trivially different* way:
> 
> for x in seq:
> do_something()
> if condition:
> break
> if another_condition:
> break

But that loop has 3 exits, written in two different ways. Why the special case?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Saturday, June 4, 2016 at 3:00:36 PM UTC+12, Steven D'Aprano wrote:
> You can exit a loop because you have run out of items to process, or you can
> exit the loop because a certain condition has been met.

But why should they be expressed differently?

item_iter = iter(items)
while True :
item = next(item_iter, None)
if item == None :
break
if is_what_i_want(item) :
break
#end while
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Christopher Reimer]

On 6/3/2016 7:31 PM, Steven D'Aprano wrote:


On Sat, 4 Jun 2016 09:06 am, Sayth Renshaw wrote:


I cant create a list with an append method pf.append(thing) in one go .

Correct. You cannot append to a list until the list exists.

Nor can you uppercase a string until the string exists:

s = "hello world"
s = s.uppercase()


>>> s = "hello world".upper()
>>> print(s)
HELLO WORLD

This works in Python 3. Not sure if s.uppercase() was meant as an 
example for a different language.


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

Re: Multiple inheritance, super() and changing signature

[Ian Kelly]

On Jun 3, 2016 7:12 PM, "Gregory Ewing"  wrote:
>
> 4. It must not matter what order the methods in a super
> chain are called. This is because you cannot predict
> which method a given super call will invoke. It could
> belong to a subclass of the class making the call.

It can't belong to a subclass; the MRI guarantees that. But it's not
necessarily a superclass either.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Catch exception with message?

[Piyush Verma]

Below is exception type and it is user defined exception. I do not see
error number in exception stack. What other option we can use as
filter in below exception apart from message?

UserDefinedException: User defined message: {}
#012  File "/opt/cio/lib/python2.7/site-packages/manager.py", line
1100, in create_from_abc
#012yield self.create(x, name, description)
#012  File "/opt/cio/lib/python2.7/site-packages/manager.py", line
1132, in create
#012'errors.create.type_not_supported.{0}'.format(abc['type']),


On Sat, Jun 4, 2016 at 6:12 AM, Random832  wrote:
> On Fri, Jun 3, 2016, at 19:14, Piyush Verma wrote:
>> Generally we catch exception using
>> except Exception as e:
>>
>> But sometimes, we see same type of exception is present with different
>> message.Is there a way to capture same exception with message
>> filtering? Please help me to do this.
>
> The message is meant to be human-readable, and may change without
> warning. Is there no other property on the exceptions you want to catch
> that can be used to distinguish them? (errno, perhaps?) What's your
> specific use case?
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list