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

2016-06-04 Thread Paul Rudin 
Nobody  writes:

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

Don't confuse consideration with agreement - they're seperate legal
concepts.

Agreement is certainly necessary in pretty much all
jurisdictions. Consideration is required in most common law jurisdiction
(England, the US, most of the commonwealth) but not in many continental
legal systems.



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

Nope - the user promises to abide by the terms of the licence. This is a
very common kind of consideration.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2016-06-04 Thread Paul Rudin 
Lawrence D’Oliveiro  writes:


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

Damages for breach of contract are supposed to reflect the loss you
suffered as a result. A nominal award is basically saying, yes - the
other guy has failed to fulfil his contractual promise, but you haven't
actually suffered any real loss as a result.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2016-06-04 Thread Paul Rudin 
Lawrence D’Oliveiro  writes:

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

But that's exactly what a contract is - an agreement. The licence is an
example, on the one side the copyright holder is agreeing not to sue the
user for copyright infringment and on the other the user is agreeing to
only use the code according to the terms.

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

You can agree a contract by conduct...
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2016-06-04 Thread Marko Rauhamaa 
Paul Rudin :

> Don't confuse consideration with agreement - they're seperate legal
> concepts.
>
> Agreement is certainly necessary in pretty much all jurisdictions.
> Consideration is required in most common law jurisdiction (England,
> the US, most of the commonwealth) but not in many continental legal
> systems.

Thankfully, I live in a jurisdiction where things are simpler. I've
actually successfully represented a relative in a court of law without
any legal training.

In Finland, it is common for families to have a printed copy of the law
on the bookshelf. Families traditionally sort out things like
inheritances without the involvement of lawyers. Nowadays, the law is
available online, of course.


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

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

2016-06-04 Thread Steven D'Aprano 
On Sat, 4 Jun 2016 12:50 pm, Christopher Reimer wrote:

>> Nor can you uppercase a string until the string exists:
>>
>> s = "hello world"
>> s = s.uppercase()
> 
>  >>> s = "hello world".upper()
>  >>> print(s)
> HELLO WORLD


"hello world" creates a string. Then you call .upper() on that string.

Perhaps a better example (demonstrating the impossibility) would be:

s = .upper()

but I thought that would not be clear.


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

Nope, just not the clearest example.



-- 
Steven

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

Re: for / while else doesn't make sense

2016-06-04 Thread Steven D'Aprano 
On Sat, 4 Jun 2016 01:41 pm, Lawrence D’Oliveiro wrote:

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


Is that a serious question? Are you really questioning the need for
for-loops to stop iterating when they reach the end of the sequence or
iterator?

I'll give you the benefit of the doubt and assume you're not trolling.

A for-loop without "the special case" as you put it, would be an infinite
loop that loops forever unless you explicitly checked for an undefined
value:

for x in [1, 2, 3]:
print(x, end='')

# prints 1 2 3 UNDEFINED UNDEFINED UNDEFINED UNDEFINED ... 


meaning practically every loop would have to be written as:

for x in seq:
   if x is UNDEFINED:
   break
   process(x)


But at least now you don't have the cognitive burden of remembering that
for-loops are intended to loop over a finite number of items, then stop.

Alternatively, we could just have the for-loop raise an exception when it
passes the end of the sequence. For extra programming machismo, have it
dump core.

Thus the programmer would be responsible for (somehow!) determining how many
times it is safe to loop. This wouldn't be too onerous for sequences:

biggest = len(seq) - 1:
if biggest > -1:
for i, x in enumerate(seq):
process(x)
if i == biggest:
break


but I leave dealing with iterators as an exercise for the masochistic.


-- 
Steven

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

Re: for / while else doesn't make sense

2016-06-04 Thread Ned Batchelder 
On Friday, June 3, 2016 at 11:43:33 PM UTC-4, Lawrence D’Oliveiro wrote:
> 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

Do you actually write loops like this? If this appeared in a code
review, first we'd have a conversation about what this code was
meant to do, and then I would ask, "Why aren't you using a for loop?"
I suspect most Python programmers would be similarly confused about
why you aren't using one of the central constructs of the language.

What's next? "Why have both if and while? A goto will work for both!"

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

Is there any way to use the logging module adding nothing to a message

2016-06-04 Thread cl 
I want to use Python to handle the stdout logging that comes from
syncthing.

When you run syncthing it logs to stdout in a fairly standard format
with date, time, ERROR/WARNING/INFO etc. so I don't want to add these.
I just want to be able to write the log to a file with appropriate
rotation etc.

If I do:-

f = logging.handlers.RotatingFileHandler("/home/chris/tmp/mail.log", 'a', 
100, 4)
f.setLevel(logging.DEBUG)
formatter = logging.Formatter('%(message)s')
f.setFormatter(formatter)
log.addHandler(f)

Will I get just the message with no extras added by the logging module?


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

Re: Multiple inheritance, super() and changing signature

2016-06-04 Thread Gregory Ewing 

Ian Kelly wrote:


It can't belong to a subclass; the MRI guarantees that. But it's not
necessarily a superclass either.


Er, yes, what I really meant to say was that it could
be a class that got introduced into the MRO as a result
of someone else subclassing your class.

So when you make a super call, you really have *no idea*
what it's going to call.

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

Re: Multiple inheritance, super() and changing signature

2016-06-04 Thread Gregory Ewing 

Steven D'Aprano wrote:

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

there is no need to use super. 


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


And if you *do* use super, you're precluding integrating them
into other hierarchies that *don't* use super. You can't win.

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

Re: Is there any way to use the logging module adding nothing to a message

2016-06-04 Thread Ben Finney 
[email protected] writes:

> If I do:-
>
> f = logging.handlers.RotatingFileHandler("/home/chris/tmp/mail.log", 'a', 
> 100, 4)
> f.setLevel(logging.DEBUG)
> formatter = logging.Formatter('%(message)s')
> f.setFormatter(formatter)
> log.addHandler(f)
>
> Will I get just the message with no extras added by the logging module?

Yuo have the code, and presumably the system on which to test it. What's
the answer?

-- 
 \  “I am too firm in my consciousness of the marvelous to be ever |
  `\   fascinated by the mere supernatural …” —Joseph Conrad, _The |
_o__) Shadow-Line_ |
Ben Finney

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

Re: Is there any way to use the logging module adding nothing to a message

2016-06-04 Thread cl 
Ben Finney  wrote:
> [email protected] writes:
> 
> > If I do:-
> >
> > f = logging.handlers.RotatingFileHandler("/home/chris/tmp/mail.log", 
> > 'a', 100, 4)
> > f.setLevel(logging.DEBUG)
> > formatter = logging.Formatter('%(message)s')
> > f.setFormatter(formatter)
> > log.addHandler(f)
> >
> > Will I get just the message with no extras added by the logging module?
> 
> Yuo have the code, and presumably the system on which to test it. What's
> the answer?
> 
Very true, I thought the code was going to be much longer than that.
:-)

... and the answer is, yes, with the above I just get the message text
which is what I want.

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

Re: for / while else doesn't make sense

2016-06-04 Thread BartC 

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

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


You mean like this:

 while True:
if a: break

 while True:
if a: break
...
if b: break

 while True:
if a: break
...
if b: break
...
if c: break


The for-statement in C handles most of my looping requirements.


(Yeah, you might find that does 'if' and 'goto' does as well! As well as 
most other control flow statements including multi-level breaks.)


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

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

2016-06-04 Thread Makoto Kuwata 
On Sat, Jun 4, 2016 at 3:15 AM, MRAB  wrote:

> On 2016-06-03 06:48, Makoto Kuwata wrote:
>
> On Fri, Jun 3, 2016 at 9:31 AM, MRAB > [email protected]>> 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.
>

Maybe.
I want to know why it happens on Python >= 3.4 and not on Python <= 3.3.

It happens on both Linux (ubuntu 14.04) and MacOSX (El Captain).

--
regards,
makoto
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multiple inheritance, super() and changing signature

2016-06-04 Thread Steven D'Aprano 
On Sat, 4 Jun 2016 09:52 pm, Gregory Ewing wrote:

> Ian Kelly wrote:
>> 
>> It can't belong to a subclass; the MRI guarantees that. But it's not
>> necessarily a superclass either.
> 
> Er, yes, what I really meant to say was that it could
> be a class that got introduced into the MRO as a result
> of someone else subclassing your class.
> 
> So when you make a super call, you really have *no idea*
> what it's going to call.

That's the nature of inheritance in a MI world. If you try to specify a
particular superclass manually, you're in the position of the archetypal
drunk looking for his lost car keys under a street light "because the light
is better here". Sure, you always know which class you're calling, but
sometimes its the wrong class!

That's the mind-twisting part of MI. Just because your class inherits from
K, doesn't mean that you should be calling K's methods. Until you (generic
you) come to terms with that, you're going to struggle with MI regardless
of what you do.

It might help to read Michele Simionato's articles about super, multiple
inheritance and related topics. Michele has been working with issues
related to MI for many years and has a lot to say about them.

Things to know about super:
Part 1 http://www.artima.com/weblogs/viewpost.jsp?thread=236275
Part 2 http://www.artima.com/weblogs/viewpost.jsp?thread=236278
Part 3 http://www.artima.com/weblogs/viewpost.jsp?thread=237121

The wonders of super:
http://www.artima.com/weblogs/viewpost.jsp?thread=281127

Mixins considered harmful:
Part 1 http://www.artima.com/weblogs/viewpost.jsp?thread=246341
Part 2 http://www.artima.com/weblogs/viewpost.jsp?thread=246483
Part 3 http://www.artima.com/weblogs/viewpost.jsp?thread=254367
Part 4 http://www.artima.com/weblogs/viewpost.jsp?thread=254507

Traits as an alternative to MI and mixins:
http://www.artima.com/weblogs/viewpost.jsp?thread=246488

Generic functions as an alternative to mixins:
http://www.artima.com/weblogs/viewpost.jsp?thread=237764

The Method Resolution Order:
https://www.python.org/download/releases/2.3/mro/



Michele wrote:

"... the problem is multiple inheritance itself. Inheritance makes your code
heavily coupled and difficult to follow (spaghetti inheritance). I have not
found a real life problem yet that I could not solve with single
inheritance + composition/delegation in a better and more maintainable way
than using multiple inheritance."


and I think that is the most valuable lesson here. MI itself is, if not an
anti-pattern, at least a dangerous one.



-- 
Steven

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

Re: Multiple inheritance, super() and changing signature

2016-06-04 Thread Nagy László Zsolt 

>
> Things to know about super:
> Part 1 http://www.artima.com/weblogs/viewpost.jsp?thread=236275
> Part 2 http://www.artima.com/weblogs/viewpost.jsp?thread=236278
> Part 3 http://www.artima.com/weblogs/viewpost.jsp?thread=237121
>
> The wonders of super:
> http://www.artima.com/weblogs/viewpost.jsp?thread=281127
>
> Mixins considered harmful:
> Part 1 http://www.artima.com/weblogs/viewpost.jsp?thread=246341
> Part 2 http://www.artima.com/weblogs/viewpost.jsp?thread=246483
> Part 3 http://www.artima.com/weblogs/viewpost.jsp?thread=254367
> Part 4 http://www.artima.com/weblogs/viewpost.jsp?thread=254507
>
> Traits as an alternative to MI and mixins:
> http://www.artima.com/weblogs/viewpost.jsp?thread=246488
>
> Generic functions as an alternative to mixins:
> http://www.artima.com/weblogs/viewpost.jsp?thread=237764
>
> The Method Resolution Order:
> https://www.python.org/download/releases/2.3/mro/
>
Very good links! This will be a good recreational reading for the next
two days.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Catch exception with message?

2016-06-04 Thread Peter Pearson 
On Sat, 4 Jun 2016 04:44:30 +0530, Piyush Verma <[email protected]> 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.

Just to make sure, . . . are you aware that "except Exception" is
generally not what you want to do, that you generally want to say
"except ValueError" or "except KeyError" or "except UnicdeDecodeError"
or something specific like that?  Maybe that's where to find the
specificity you seek.

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

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

2016-06-04 Thread Terry Reedy 

On 6/4/2016 4:24 AM, Marko Rauhamaa wrote:

Paul Rudin :


Don't confuse consideration with agreement - they're seperate legal
concepts.

Agreement is certainly necessary in pretty much all jurisdictions.
Consideration is required in most common law jurisdiction (England,
the US, most of the commonwealth) but not in many continental legal
systems.


Thankfully, I live in a jurisdiction where things are simpler. I've
actually successfully represented a relative in a court of law without
any legal training.

In Finland, it is common for families to have a printed copy of the law
on the bookshelf.


How wonderful that 'the law' can fit in a book.  English-speaking common 
law commentaries once had Blackstone's 4 volume Commentaries 
(https://en.wikipedia.org/wiki/William_Blackstone#Commentaries_on_the_Laws_of_England), 
but bookshelve of statute laws seem to have overwhelmed that, at least 
in the US.


> Families traditionally sort out things like

inheritances without the involvement of lawyers. Nowadays, the law is
available online, of course.


For free, I presume.  I just discovered that the Delaware Code is now 
online http://delcode.delaware.gov/index.shtml.



--
Terry Jan Reedy

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

Anyone know a donation app codebase?

2016-06-04 Thread Albert 
Hello,

Anyone knows a donation app whose code is available on github or similar made 
in python (could be django, flask, or any other web framework).

Thank you very much.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Anyone know a donation app codebase?

2016-06-04 Thread Ben Finney 
Albert  writes:

> Anyone knows a donation app whose code is available on github or
> similar made in python (could be django, flask, or any other web
> framework).

Search for Python libraries on the Python Package Index
https://pypi.python.org/>.

What you are (I think) looking for can be called a “payment” handler
https://pypi.python.org/pypi?%3Aaction=search&term=payment&submit=search>.
If that's not right you can try different search terms.

-- 
 \ “My, your, his, hers, ours, theirs, its. I'm, you're, he's, |
  `\   she's, we're, they're, it's.” —anonymous, alt.sysadmin.recovery |
_o__)  |
Ben Finney

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

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

2016-06-04 Thread Marko Rauhamaa 
Terry Reedy :

> On 6/4/2016 4:24 AM, Marko Rauhamaa wrote:
>> In Finland, it is common for families to have a printed copy of the
>> law on the bookshelf.
>
> How wonderful that 'the law' can fit in a book.

Must be abridged, although I'm not sure.

>> Families traditionally sort out things like inheritances without the
>> involvement of lawyers. Nowadays, the law is available online, of
>> course.
>
> For free, I presume.  I just discovered that the Delaware Code is now
> online http://delcode.delaware.gov/index.shtml.

Yes, for free.

California, too, has posted its laws online. However, the traditions are
different in that American laws aren't the whole story: you'll also have
to know the precedents. Precedents play a role in Finland, as well, but
here laws tend to be more specific and precedents don't bind courts so
strongly.

AFAIK, American precedents are *not* freely available. Precedent
databases are available only for a fee to law firms. Thus, only lawyers
can hope to know what the de-facto law is. The online statutes don't
give you nearly enough information. (I once tried to figure out who was
supposed to yield in a tricky merging situation in California. The
California Vehicle Code didn't seem to provide any principle that would
have given the right answer. While perusing the laws, I did notice that
the DMV driving recommendations for a large part don't seem to be based
on the Vehicle Code. For example, I couldn't find any mention of
interleaving in the Code.)


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

Re: Recommendation for GUI lib?

2016-06-04 Thread John Pote 

On 02/06/2016 22:57, Dietmar Schwertberger wrote:


On 02.06.2016 12:35, John Pote wrote:
I've used wxPython (www.wxpython.org) for a few GUI projects and 
found it ok. It's a wrapper for the wxWidgets C++ library. There's 
even a reasonable free GUI builder, wxGlade, which I use as I prefer 
constructing GUI's that way rather than writing raw wxPython code. 
Never tried any of the paid for GUI builders.
Disadvantage is the download page only provides builds for Python 2.6 
or 2.7.


Does anyone know how Project Phoenix is coming on? 
http://wxpython.org/Phoenix/ItsAlive/ shows wxPython working with 
Python 3.2.

Comments on how stable it is and how easy to install would be helpful.
I have been using Phoenix now for half a year and are very happy with 
it. A release is on its way. For most platforms there are snapshot 
builds which are easy to install.


See e.g. 
https://groups.google.com/d/msg/wxpython-users/soHFLOrerVs/MSijBTQ6KAAJ



The snapshot installation does not include the demo and the .chm help 
file (yet?). These and the book I found to be the most helpful 
resources (much more usable than online reference documentation as 
e.g. with Qt).



I think that wxGlade is the most promising Python GUI builder and I'm 
confident that it will see improvements to increase usability. I have 
tried some others from time to time, including also QtCreator, but 
none was really convincing.


Regards,

Dietmar

Qt and Qt Creator often come up in searches for Python GUI libraries. I 
need to decide weather to upgrade to wxPython.Phoenix and Python 3.5 (as 
soon as I upgrade to win 7!) or switch to Qt which I don't know at all. 
It would be interesting to hear your experiences of trying Qt and why 
you've stuck with wxPython in the end.


Thanks,
John

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

Re: Catch exception with message?

2016-06-04 Thread Lawrence D’Oliveiro 
On Sunday, June 5, 2016 at 4:44:17 AM UTC+12, Peter Pearson wrote:

> ... are you aware that "except Exception" is generally not what you want to
> do ...

Agree. Always make your “except”-matching as specific as possible.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2016-06-04 Thread Lawrence D’Oliveiro 
On Saturday, June 4, 2016 at 3:55:12 AM UTC+12, Matt Wheeler wrote:
> 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.

I have made heavy use of Python as well as many other languages, and I don’t 
know what you mean. What “other languages” are you thinking of?

Are variables like little boxes? Yes they are. But they are all the same size, 
while objects may be large (even very large) or small. That is why variables 
hold, not objects, but references to objects.

(This makes no difference for immutable objects, only mutable ones.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

2016-06-04 Thread Lawrence D’Oliveiro 
On Saturday, June 4, 2016 at 9:27:58 PM UTC+12, Steven D'Aprano wrote:
> Are you really questioning the need for for-loops to stop iterating
> when they reach the end of the sequence or iterator?

I just want to point out how you turn a discussion about the behaviour of loops 
into one about the behaviour of for-loops specifically.

> I'll give you the benefit of the doubt and assume you're not trolling.

Please, do not make this personal. That’s a sign of running out of rational 
things to say.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

2016-06-04 Thread Lawrence D’Oliveiro 
On Saturday, June 4, 2016 at 11:37:18 PM UTC+12, Ned Batchelder wrote:
> On Friday, June 3, 2016 at 11:43:33 PM UTC-4, Lawrence D’Oliveiro wrote:
> > 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
> 
> Do you actually write loops like this?

Is that a non-trolling question? Yes. All the time.

> If this appeared in a code review, first we'd have a conversation about
> what this code was meant to do ...

I would hope not.

> ...and then I would ask, "Why aren't you using a for loop?"

... and then I would ask, “Didn’t you read my previous postings where I pointed 
out the issues with them?”

Here  is another 
example: see the section “Looping on Field Breaks”. A while-True scales 
gracefully to complex situations like that. I much prefer universal, adaptable 
constructs, rather than having to remember different solutions for special 
cases.

> I suspect most Python programmers would be similarly confused about
> why you aren't using one of the central constructs of the language.

When a language has good and bad parts, it behooves the wise programmer to 
concentrate on the good parts and try to ignore the bad.

Python’s for-loops have their uses—I *did* point this out too, did you not 
notice?—but they are best confined to the situations that they are good at.

> What's next? "Why have both if and while? A goto will work for both!"

Passive-aggression aside, funny you should mention that. I use a goto-free 
structured-programming style in my C code, as exemplified here 
. I find it 
reduces problems with forgetting to free memory, or freeing it twice.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2016-06-04 Thread Random832 
On Fri, Jun 3, 2016, at 22:02, Steven D'Aprano wrote:
> (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.)

Technically, there are statutory usage rights; 17 USC 117 (a) (1):

(a)Making of Additional Copy or Adaptation by Owner of
Copy.—Notwithstanding the provisions of section 106, it is not an
infringement for the owner of a copy of a computer program to make or
authorize the making of another copy or adaptation of that computer
program provided:
(1) that such a new copy or adaptation is created as an essential step
in the utilization of the computer program in conjunction with a machine
and that it is used in no other manner, or
(2) that such new copy or adaptation is for archival purposes only and
that all archival copies are destroyed in the event that continued
possession of the computer program should cease to be rightful.

The proprietary software industry's continued ability to make demands in
an EULA rests on a rather shaky (though less than it was in the
box-full-of-disks days) theory that buying software does not in fact
make you the "owner of a copy", something that open-source types don't
tend to claim regarding their own software.

(IANAL either of course)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Coding systems are political (was Exended ASCII and code pages)

2016-06-04 Thread Rustom Mody 
On Monday, May 30, 2016 at 12:16:55 AM UTC+5:30, Terry Reedy wrote:
> On 5/29/2016 2:12 AM, Rustom Mody wrote:
> 
> > In short that a € costs more than a $ is a combination of the factors
> > - a natural cause -- there are a million chars to encode (lets assume that 
> > the
> > million of Unicode is somehow God-given AS A SET)
> > - an artificial political one -- out of the million-factorial permutations 
> > of
> > that million, the one that the Unicode consortium chose is towards 
> > satisfying the
> > equation: Keep ASCII users undisturbed and happy
> 
>  From the Python developer viewpoint, Unicode might as well be a fact of 
> nature.  I also note that in English text, a (phoneme) char conveys 
> about 6 bits of information, while in Chinese text, a (word) char 
> conveys perhaps 15 bits of information.  So I argue that Python 3.3+'s 
> FSR is being fair in using 1 byte for the first and most often 2 bytes 
> for the other.

Almost a fact of nature -- thats right
Im making no complaint against python
Or unicode for that matter.

Bismarck's well-known quote: Politics is the art of the possible
not so well-known additional clause "... the art of the second best"

Unicode's relation to ASCII is analogous to C++ relation to C.
Ask a typical C++ programmer about style/paradigm etc and you'll hear something
unctuous about how C-style is terrible.
Then ask why the question of C arises at all when its so unfit and obsolete
ie why build C++ on a C base
And you'll get vague, philosophical BS on pragmatism etc

In short when it suits exploit C, when it suits abuse it.

Unicode is likewise:
The whole point of unicode is to go beyond ASCII
And yet ASCII is allocated the prime real-estate of the lowest 128
of ASCII -- all the control-char wastage preserved intact
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2016-06-04 Thread Steven D'Aprano 
On Sun, 5 Jun 2016 01:17 pm, Lawrence D’Oliveiro wrote:

> On Saturday, June 4, 2016 at 3:55:12 AM UTC+12, Matt Wheeler wrote:
>> 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.
> 
> I have made heavy use of Python as well as many other languages, and I
> don’t know what you mean. What “other languages” are you thinking of?
> 
> Are variables like little boxes? Yes they are. 

That's *exactly* what variables in Python are not like.


> But they are all the same 
> size, while objects may be large (even very large) or small. That is why
> variables hold, not objects, but references to objects.

No they don't. You are confusing the implementation with the programming
model.

Following the assignment:

x = 99

if you print(x), do you see something like "reference 0x12345"? No.

Do you have to dereference that reference to get the value of x? No.

At the Python level, the value of x is 99, not some invisible, untouchable
reference to 99.

There is no analog to dereferencing in Python, nothing like print(x^). You
bind values (that is, objects) directly to names, and names (variables)
hold their value, not a reference to their value.

The fact that for some implementations that is implemented using references
of some sort or another (e.g. pointers in CPython) is an implementation
detail which is irrelevant to the language and its execution model.



-- 
Steven

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

Re: for / while else doesn't make sense

2016-06-04 Thread Steven D'Aprano 
On Sun, 5 Jun 2016 01:29 pm, Lawrence D’Oliveiro wrote:

> On Saturday, June 4, 2016 at 11:37:18 PM UTC+12, Ned Batchelder wrote:
>> On Friday, June 3, 2016 at 11:43:33 PM UTC-4, Lawrence D’Oliveiro wrote:
>> > 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
>> 
>> Do you actually write loops like this?
> 
> Is that a non-trolling question? Yes. All the time.

Really? Well, you'd fail my code review, because that code is broken. If
items contains None, your loop will silently end early. That's a bug.


>> If this appeared in a code review, first we'd have a conversation about
>> what this code was meant to do ...
> 
> I would hope not.

Clearly. Nevertheless, its a conversation that needs to be had.


>> ...and then I would ask, "Why aren't you using a for loop?"
> 
> ... and then I would ask, “Didn’t you read my previous postings where I
> pointed out the issues with them?”

I don't think that very many people would agree with you or consider them
problems at all. They're more like features than problems. Your objections
to for-loops feel kind of like "I don't like bread knives because they make
it too easy to slice bread".

Okay, you don't like for-loops, because they make looping a fixed number of
times with an optional early exit too much of a "cognitive burden" for you.
You have my sympathy, but nobody else I've come across in nearly two
decades of Python programming finds them a cognitive burden.


> Here  is
> another example: see the section “Looping on Field Breaks”. 

That section was written by you and is not independent confirmation that
others agree with your issues with for-loops.


> A while-True scales gracefully to complex situations like that.

Graceful like a hippopotamus.

I don't know that the situation is complex, your description is pretty clear
and to the point:

Consider the following scenario: your sales company database has
a table of employees, and also a table of sales made by each
employee. You want to loop over these sale entries, and produce
some per-employee statistics.

but the while loop you have certainly is complex. If I understand your
intent correctly, then I think this is both more elegant and likely faster
than the while loop you use:


# Beware of bugs in the following code: 
# I have only proven it is correct, I haven't tested it.
rows = db_iter(
db = db,
cmd =
"select employees.name, sales.amount, sales.date from"
" employees left join sales on employees.id = sales.employee_id"
" order by employees.name, sales.date"
)
default = {'total sales': 0.0,
   'number of sales': 0,
   'earliest date': None,
   'latest date': None}
prev_employee_name = None
stats = {}
for (employee_name, amount, date) in rows:
if (employee_name != prev_employee_name 
and prev_employee_name is not None):
# Print the previous employee's stats
report(prev_employee_name, stats)
# and prepare for the next employee.
previous_employee_name = employee_name
stats = default.copy()
stats['total sales'] += amount
stats['number of sales'] += 1
if stats['earliest date'] is None:
stats['earliest date'] = date
stats['latest date'] = date

if prev_employee_name is not None:
report(prev_employee_name, stats)


No breaks needed at all, which makes it much more understandable: you know
instantly from looking at the code that it processes every record exactly
once, then exits.

But it is a *tiny* bit ugly, due to the need to print the last employee's
statistics after the loop is completed. We can fix that in two ways:

(1) Give up the requirement to print each employee's stats as they are
completed, and print them all at the end; or

(2) Put a sentinel at the end of rows.


The first may not be suitable for extremely large data sets, but it is
especially elegant:


rows = db_iter( ... # as above )
default = {'total sales': 0.0, 
   'number of sales': 0,
   'earliest date': None,
   'latest date': None}
stats = {}
for (employee_name, amount, date) in rows:
record = stats.setdefault(employee_name, default.copy())
stats['total sales'] += amount
stats['number of sales'] += 1
if stats['earliest date'] is None:
stats['earliest date'] = date
stats['latest date'] = date
for employee_name in stats:
report(employee_name, stats[employee_name])


As you now have all the statistics available, yo

Spread a class over multiple files

2016-06-04 Thread Mark Summerfield 
Sometimes I want to spread a class over multiple files.

My primary use case is when I create a "Model" class to reflect an entire SQL 
database. I want a model instance to provide a single point of access to the 
database, but the database has many tables each requiring its own methods since 
they differ in their structure, purpose, validation needs, etc.

A secondary use case is when I create "MainWindow" classes in GUI programming 
and have lots of methods to reflect all the actions (e.g., menu options and 
toolbar actions, plus interaction with the main widget(s)).

To meet these needs I've devised an approach that I think is easy to use and 
understand and which doesn't use any tricky or hard to maintain code.

My question is -- are there nicer/better ways to achieve this?

Here's a summary of my approach. A fuller discussion is on my website:
https://www.qtrac.eu/pyclassmulti.html

# Lib.py
# This provides the two functions (both decorators) used to support my approach
def add_methods_from(*modules):
def decorator(Class):
for module in modules:
for method in getattr(module, "__methods__"):
setattr(Class, method.__name__, method)
return Class
return decorator

def register_method(methods): # A decorator used purely for its side-effect
def register_method(method):
methods.append(method)
return method # Unchanged and not strictly necessary
return register_method

# Model.py
# This provides my model but some methods are in separate files
import Lib
import _ModelConfig
import _ModelOutput

@Lib.add_methods_from(_ModelConfig, _ModelOutput)
class Model:
...
def small_method(self):
...

# _ModelConfig # _ModelOutput has the same structure so not shown
import Lib
__methods__ = [] # self is a Model

@Lib.register_method(__methods__)
def config(self):
...

So, that's the overall pattern of my solution. I know that I could use 
functools partial, e.g.,

register_method = functools.partial(Lib.register_method, __methods__)

...

@register_method
def config(self):
...

So, is there a nicer/better way? Could I cleanly avoid the explicit imports 
(e.g., import _ModelConfig), without resorting to stack frame hacks or similar?
-- 
https://mail.python.org/mailman/listinfo/python-list

Operator precedence problem

2016-06-04 Thread ICT Ezy 
>>> 2 ** 3 ** 2 
Answer is 512
Why not 64?
Order is right-left or left-right?
-- 
https://mail.python.org/mailman/listinfo/python-list