Re: Expression can be simplified on list

2016-09-14 Thread Rustom Mody
On Wednesday, September 14, 2016 at 10:23:12 AM UTC+5:30, Steven D'Aprano wrote:
> On Wednesday 14 September 2016 13:59, Lawrence D’Oliveiro wrote:
> 
> > On Wednesday, September 14, 2016 at 2:25:48 PM UTC+12, Ben Finney wrote:
> >> Lawrence D’Oliveiro writes:
> >> 
> >> > It would be better if all such conversions were explicit
> >> 
> >> Why? It's entirely unambiguous ...
> > 
> > 
> 
> 
> *shrug* 
> 
> And if somebody designed an iterator that behaved badly or surprisingly, 
> would 
> you conclude that the entire concept of iteration is therefore broken?
> 
> The midnight gotcha was (it has now been fixed) a design bug of the class. As 
> simple as that.

Quite the contrary
I showed if you remember that for regular expressions, dfas, graphs
the questions of when is one of these falsey is highly non-trivial.

In more general terms:
For complex data-types, the exact specific nature of which is ‘trivial’ may
be a highly non-trivial question.

About the python builtins — list, tuple, string, dict — for which these
questions seem straightforward and obvious:
In Haskell there is a type-class called Functor which informally corresponds
to collection type.
More formally for a type to be a functorial type it needs too have a
binary op and a constant.
For python lists it would be +, []
For sets ‘|’ (union ie ‘∪’ ) and ∅
etc
satisfying some mathematical properties which (being a bit fast and loose)
say that the operation, element need to be monoidal
ie the operation needs to be associative and element needs to be its identity

In THOSE TYPES that element can justifiably serve as a falsey (empty) type

However to extrapolate from here and believe that ALL TYPES can have a falsey 
value meaningfully, especially in some obvious fashion, is mathematically 
nonsense.

Mathematical gobbledygook of no interest? Ok here’s a 

tl;dr

1. Go back to this post’s OP. Is it not an authentic question?
2. Is something like it not a FAQ?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]

2016-09-14 Thread Steven D'Aprano
On Wednesday 14 September 2016 16:54, Rustom Mody wrote:

> everything we know will be negated in 5-50-500 years


I'm pretty sure that in 5, 50, 500 or even 5000 years, the sun will still rise 
in the east, water will be wet, fire will burn, dogs will have mammary glands 
and frogs[1] won't, and the square root of 100 will still be 10.

Isaac Asimov once wrote:

When people thought the earth was flat, they were wrong. When people
thought the earth was spherical, they were wrong. But if you think that
thinking the earth is spherical is just as wrong as thinking the earth
is flat, then your view is wronger than both of them put together.



http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm





[1] Assuming that there are any frogs left by then.

-- 
Steven
git gets easier once you get the basic idea that branches are homeomorphic 
endofunctors mapping submanifolds of a Hilbert space.

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


Re: Expression can be simplified on list

2016-09-14 Thread Rustom Mody
On Wednesday, September 14, 2016 at 10:17:27 AM UTC+5:30, Steven D'Aprano wrote:
> You're perfectly entitled to dislike duck-typed truthiness. But that makes 
> the 
> majority of dynamically-typed languages (like Python, Javascript, Ruby, Lua 
> and 
> more) a bad fit for your way of thinking.

Yes and No
Here is elisp, one more such dynamic language:
Here is the docs for null and not:

null is a built-in function in `C source code'.

(null OBJECT)

Return t if OBJECT is nil.
null is a built-in function in `C source code'.

(null OBJECT)

Return t if OBJECT is nil.



not is an alias for `null' in `subr.el'.

(not OBJECT)

Return t if OBJECT is nil.



So null and not are the same function ie synonyms
The result of this is that most of these kind of discussions are side-stepped
even though the under-belly of lisp is quite like python:

Just use not when you want to think in terms of bools and null when you want to
think in terms of lists

To be fair, this is the situation in lisp prior to scheme
Scheme introduced #t and #f analogous to python 2.3(?) introducing
True and False
With all the attendant increased confusion from arcanity
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Python inner function parameter shadowed

2016-09-14 Thread Steven D'Aprano
On Wednesday 14 September 2016 13:58, Lawrence D’Oliveiro wrote:

> On Wednesday, September 14, 2016 at 4:34:34 AM UTC+12, Daiyue Weng wrote:
>> PyCharm warns about "Shadows name 'func' from outer scope"
> 
> Typical piece of software trying to be too helpful and just getting in the
> way.
> 
> Can you turn off such warnings?

Yes.

It is the job of the linter to be pedantic and opinionated. A good linter will
let you turn off warnings globally and locally, permanently and temporarily. I
don't know how good PyCharm is, but you can certainly configure it to turn off
selected warnings:

https://www.jetbrains.com/help/pycharm/2016.1/disabling-and-enabling-inspections.html

https://www.jetbrains.com/help/pycharm/2016.1/suppressing-inspections.html




-- 
Steven
git gets easier once you get the basic idea that branches are homeomorphic
endofunctors mapping submanifolds of a Hilbert space.

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


Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]

2016-09-14 Thread Lawrence D’Oliveiro
On Wednesday, September 14, 2016 at 6:54:39 PM UTC+12, Rustom Mody wrote:
> Yet we remain cocksure of our assumtions inspite of the repeated data
> that everything we know will be negated in 5-50-500 years

Let’s see, 500 years ago, people knew
* That the world is round, and how to measure its radius to within a third of a 
percent of the modern value
* That the square root of 2 cannot be represented as an exact ratio of two 
integers
* That objects float in water because their density is lower than that of water
* That the optimum shape for a load-bearing arch is a catenary
* That blood in the human body has to take the long way round--through the 
lungs--to get from one side of the heart to the other
* That Roman numerals are a stupid way to do calculations.

Have any of these been disproved yet? I’m not up with all these “there is no 
objective reality, everything is relative” ideas as yet...
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Expression can be simplified on list

2016-09-14 Thread Steven D'Aprano
On Wednesday 14 September 2016 17:16, Rustom Mody wrote:

> On Wednesday, September 14, 2016 at 10:23:12 AM UTC+5:30, Steven D'Aprano
> wrote:

>> And if somebody designed an iterator that behaved badly or surprisingly,
>> would you conclude that the entire concept of iteration is therefore broken?
>> 
>> The midnight gotcha was (it has now been fixed) a design bug of the class.
>> As simple as that.
> 
> Quite the contrary
> I showed if you remember that for regular expressions, dfas, graphs
> the questions of when is one of these falsey is highly non-trivial.

No, you *claimed* to have done so, but you actually didn't.

I'm not sure if it makes sense to talk about an "empty regular expression", or 
if that is the same as re.compile(''). Presumably if such a thing makes sense, 
it would match nothing, from any input at all. If so, that could be falsey and 
all non-empty regexes would be truthy.

Or, since regexes aren't containers *or* numbers, you might prefer that all 
regexes are truthy. I don't mind which you pick neither view is fundamentally 
better than the other, and both are compatible with Python semantics. Decide 
according to what you think is most useful. If you can't decide, toss a coin. 
Likewise for DFAs. In neither case it is "highly non-trivial".

Graphs, on the other hand, are trivial to decide: the empty or null graph, with 
no nodes at all, is falsey. All non-empty graphs are truthy. As graphs are 
containers, no other model makes sense in the context of Python.

The problem of deciding whether a value should be considered truthy or falsey 
can be as simple or complex as the language designer likes. Python has a 
particularly simple rule, which makes the decision trivial in most 
circumstances. Other languages, perhaps not so much.

On the other hand, there is at least one scenario where forcing a boolean 
notion of truthiness *is* fundamentally difficult: many-valued logic. Once you 
introduce more than two logical values ("True", "False", "Maybe" for example), 
it is hard to decide what some of the values should be treated as.

For example, True clearly maps to boolean True, and False to boolean False; but 
what does Maybe map to? To paraphrase Billy Crystal's character in "The 
Princess Bride":

Mostly false is a little bit true


so to force the logical value "Maybe" into a True/False dichotomy will always 
require an element of arbitrary choice.

https://en.wikipedia.org/wiki/Many-valued_logic



> In more general terms:
> For complex data-types, the exact specific nature of which is ‘trivial’ may
> be a highly non-trivial question.

Hypothetically? Sure. But in practice? No.

The decision is simple: if your data type is a kind of container, then it 
should follow the rule that emptiness ≡ falsey. If it is a number, then zero is 
falsey. If it is a string of some sort, then the empty string is falsey. All 
else is truthy.

If your data type has a clear and obvious dichotomy analogous to "something 
versus nothing", "non-empty versus empty", or equivalent, then that's your 
dividing line.

If there is no such clear dichotomy, then perhaps all your values should be 
considered truthy.

In practice, it should be rare that this is a hard decision to make. In theory, 
one can state that it is hard to make this decision, but actually coming up 
with an example where it is difficult is not simple.

Perhaps the best example (apart from many-valued logic, discussed above) is in 
fact the "midnight" example. Although we use numbers to *represent* times, 
times are not themselves numbers. Unlike durations, you cannot add times: 3am 
plus 5pm is meaningless. So midnight, represented by the number zero, doesn't 
actually have the properties of number zero. It isn't the additive identity, 
nor the multiplicative nullity.

To put it another way, unlike the integer 0 or float 0.0 or complex 0+0j, 
midnight is just another time, no different from all the other times. It is an 
artefact of the implementation that it was ever falsey.


> However to extrapolate from here and believe that ALL TYPES can have a falsey
> value meaningfully, especially in some obvious fashion, is mathematically
> nonsense.

Mathematically nonsense and practically sensible. It is easy to claim that 
there are types where it is hard to decide which values should be truthy and 
which falsey, but in practice apart from many-valued logics, it is *usually* 
easy to decide.

Might there be exceptions? Of course. If you think that I've ever argued that 
there are never any exceptions, then you're arguing against a strawman. Its 
just that those exceptions are unusual: exceptional, difficult cases are 
*rare*.

(In the Python std lib, with dozens of data types, there is only *one* where 
the choice of truthiness was controversial: abstract times of the day.)





-- 
Steven
git gets easier once you get the basic idea that branches are homeomorphic 
endofunctors mapping submanifolds of a Hilbert space.

-- 
https://mail.python

%config PromptManager

2016-09-14 Thread Cecil Westerhof
In an ipy-file I have:
%config PromptManager.in_template = r'[{time.strftime("%a, %d %b %T")} 
\u@\h:\Y1]\nIn [\#]: '

This works for ipython2, but gets ipython3 in an endless loop. At the
moment I solved it with:
if sys.version_info.major != 3:
%config PromptManager.in_template = r'[{time.strftime("%a, %d %b %T")} 
\u@\h:\Y1]\nIn [\#]: '

But is there a way to do it both for ipython2 and ipython3?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list


‘pip2 install cryptography’ does not work

2016-09-14 Thread Cecil Westerhof
I try to do a:
pip2 install cryptography

But this give:
gcc -pthread -shared 
build/temp.linux-x86_64-2.7/build/temp.linux-x86_64-2.7/_openssl.o -L/usr/lib64 
-lssl -lcrypto -lpython2.7 -o 
build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/_openssl.so
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: 
/usr/lib64/libpython2.7.a(abstract.o): relocation R_X86_64_32S against 
`_Py_NotImplementedStruct' can not be used when making a shared object; 
recompile with -fPIC
/usr/lib64/libpython2.7.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1


Command "/usr/bin/python -u -c "import setuptools, 
tokenize;__file__='/tmp/pip-build-QoMAwn/cryptography/setup.py';exec(compile(getattr(tokenize,
 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" 
install --record /tmp/pip-LxpwQ4-record/install-record.txt 
--single-version-externally-managed --compile" failed with error code 1 in 
/tmp/pip-build-QoMAwn/cryptography/


What is happening here and what can I do about it?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Python inner function parameter shadowed

2016-09-14 Thread Christopher Reimer
> On Sep 13, 2016, at 8:58 PM, Lawrence D’Oliveiro  
> wrote:
> 
>> On Wednesday, September 14, 2016 at 4:34:34 AM UTC+12, Daiyue Weng wrote:
>> PyCharm warns about "Shadows name 'func' from outer scope"
> 
> Typical piece of software trying to be too helpful and just getting in the 
> way.
> 
> Can you turn off such warnings?

IIRC, if you turn off this warning, it also turns off a more useful warning 
somewhere else.

My favorite PyCharm warning bug is creating a base class with an implemented 
getter and an unimplemented setter. When the base class is inherited and the 
setter is implemented, the IDE warns that the getter is missing. The workaround 
is to implement the getter with a super call. This bug is several years old and 
no one had fixed it because it has workaround.

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


Re: [python-committers] [RELEASE] Python 3.6.0b1 is now available

2016-09-14 Thread Paul Moore
On 14 September 2016 at 11:32, Serhiy Storchaka  wrote:
> On 13.09.16 02:35, Ned Deily wrote:
>>
>> On behalf of the Python development community and the Python 3.6 release
>> team, I'm happy to announce the availability of Python 3.6.0b1. 3.6.0b1
>> is the first of four planned beta releases of Python 3.6, the next major
>> release of Python, and marks the end of the feature development phase
>> for 3.6.
>
>
> There is no mention on https://www.python.org/news/.

The last release mentioned there is 3.4.0rc1...

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


Re: Expression can be simplified on list

2016-09-14 Thread Serhiy Storchaka

On 14.09.16 11:28, Steven D'Aprano wrote:

I'm not sure if it makes sense to talk about an "empty regular expression", or
if that is the same as re.compile(''). Presumably if such a thing makes sense,
it would match nothing, from any input at all.


Actually, it matches anything. re.compile('').match(x) returns non-false 
value for any valid x.



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


Re: Expression can be simplified on list

2016-09-14 Thread Chris Angelico
On Wed, Sep 14, 2016 at 8:46 PM, Serhiy Storchaka  wrote:
> On 14.09.16 11:28, Steven D'Aprano wrote:
>>
>> I'm not sure if it makes sense to talk about an "empty regular
>> expression", or
>> if that is the same as re.compile(''). Presumably if such a thing makes
>> sense,
>> it would match nothing, from any input at all.
>
>
> Actually, it matches anything. re.compile('').match(x) returns non-false
> value for any valid x.

"Matches" has two meanings with a regex. The regular expression
"[A-Za-z]*" matches the three Q's in "123QQQ456", and thus it
successfully matches against that string. In the string "1234", the
regex still successfully matches that string, but it finds nothing,
ergo it matches an empty string in that string. Does a non-empty
string contain an empty string? Well, in the sense that ("" in "spam")
is true, yes, it does - but the empty string didn't match any of those
characters.

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


Re: Expression can be simplified on list

2016-09-14 Thread Jussi Piitulainen
Serhiy Storchaka writes:

> On 14.09.16 11:28, Steven D'Aprano wrote:

>> I'm not sure if it makes sense to talk about an "empty regular
>> expression", or if that is the same as re.compile(''). Presumably if
>> such a thing makes sense, it would match nothing, from any input at
>> all.
>
> Actually, it matches anything. re.compile('').match(x) returns
> non-false value for any valid x.

It matches the empty string. The .match method returns a match object if
the regex matches at the start of the input. See span:

re.compile('').match('foo')
===> <_sre.SRE_Match object; span=(0, 0), match=''>

There's an empty string at every position, same content, different span:

re.compile('').findall('foo')
===> ['', '', '', '']

More mathematical treatments of regular expressions usually include a
special expression that stands for the empty string, typically ε or λ,
I've also seen Λ, sometimes e -- my impression is that those sources
tend to use small alphabets, often just two or three letters, so they
can afford to give up e.

Some ruminations follow, following Rustom's mathematical ruminations,
related to extended regex software that has taken a rather different
direction from the usual matching engines.

Mathematical discussions tend to acknowledge only alternation (union),
concatenation and iteration (Kleene star) as operations, unless they
specifically focus on some other operations that can, in principle, be
expressed in terms of those three. There are many such.

Without further regex operations it makes sense to include a special
regular expression that matches nothing.  Otherwise a very simple NFA
(DFA) has no corresponding regex, which can be considered awkward.

There are powerful regex operations for which it may not be
computationally trivial, regarding time and space, to tell whether the
regex matches anything at all. Does one expect bool(o) to happen
quickly? in near-constant time? I think there tends to be some such
expectation. Then it might make practical sense to not interpret a regex
as a container of the strings that it matches, even if such an
interpretation makes some theoretical sense. It may make sense to keep
the regex and its interpretation as a set (or relation) separate in
theory, too, just for the clarity of thought.

My colleagues down the corridor deal with large finite-state automata
and transducers, applying a rich regex formalism to analyze the various
forms that words can take. Some of them used to be a challenge to
compile at all - a Greenlandish lexicon was an example. - It looks like
the move of the software to GitHub has happened: http://hfst.github.io/.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: [python-committers] [RELEASE] Python 3.6.0b1 is now available

2016-09-14 Thread Guido van Rossum
Fortunately that page isn't linked from anywhere on the home page
AFAIK. If it is, could someone file an issue in the pydotorg tracker?
The url is at the bottom of every page.

On Wed, Sep 14, 2016 at 3:41 AM, Paul Moore  wrote:
> On 14 September 2016 at 11:32, Serhiy Storchaka  wrote:
>> On 13.09.16 02:35, Ned Deily wrote:
>>>
>>> On behalf of the Python development community and the Python 3.6 release
>>> team, I'm happy to announce the availability of Python 3.6.0b1. 3.6.0b1
>>> is the first of four planned beta releases of Python 3.6, the next major
>>> release of Python, and marks the end of the feature development phase
>>> for 3.6.
>>
>>
>> There is no mention on https://www.python.org/news/.
>
> The last release mentioned there is 3.4.0rc1...
>
> Paul
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/



-- 
--Guido van Rossum (python.org/~guido)
-- 
https://mail.python.org/mailman/listinfo/python-list


What is the correct form for saying "licensed under the same terms as Python itself"?

2016-09-14 Thread Mark Summerfield
Hi,

I'm developing a small Python software library that I want to publish as free 
software under the same terms as Python itself.

I notice that a few of Python's own files begin like this:

# Copyright 2007 XXX. All Rights Reserved.
# Licensed to PSF under a Contributor Agreement.

Is this form sufficient?
Do I need to include the PSF license with the package?
(Also, I don't actually remember if I've signed a Contributor Agreement.)

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


[ANN] German translation of Python 3 Cheat Sheet

2016-09-14 Thread Laurent Pointal
Hello,

The Python 3 Sheet Cheat (Mémento Bases Python 3) has been 
translated into german by StR Martin Putzlocher. Thanks to him.

It can be downloaded on the same page as english and french
versions: https://perso.limsi.fr/pointal/python:memento

A+
L.Pointal.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Tkinter file dialog screwed

2016-09-14 Thread Kerbingamer376
On Wednesday, September 14, 2016 at 2:14:16 AM UTC+1, Steve D'Aprano wrote:
> On Wed, 14 Sep 2016 06:08 am, kerbingamer376 wrote:
> 
> > The tkinter file dialog is, for me, unusable. Whenever I try to use it, it
> > opens, but all the text is white on a white background (see this
> > http://xomf.com/qzhgy) making it unusable. This has happened on 2 linux
> > systems, both KDE plasma 5. Any help?
> 
> 
> What happens if you change your KDE theme, or use another desktop
> environment?
> 
> 
> 
> 
> -- 
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.

neither make any difference.
-- 
https://mail.python.org/mailman/listinfo/python-list


Requests for webbrowser module

2016-09-14 Thread Jamie

Hi,

I am not sure if this is an intended consequence but when using the 
webbrowser module to open a new blank browser tab in chrome it opens it 
in a new browser window instead of using the current window. Providing 
any complete url provides different behaviour, it opening a new tab in 
the current browser window. Below is some code that produces the 
different behaviours.


blank tab code:
import webbrowser

chrome = "C:/Program Files (x86)/Google/Chrome/Application/chrome.exe %s"
url = "chrome://newtab"
webbrowser.get(chrome).open_new_tab(url)
webbrowser.get(chrome).open_new_tab(url)

normal tab code:
import webbrowser

chrome = "C:/Program Files (x86)/Google/Chrome/Application/chrome.exe %s"
url = "http://google.com";
webbrowser.get(chrome).open_new_tab(url)
webbrowser.get(chrome).open_new_tab(url)

I would like to be able to open new blank tabs in the current browser 
window if possible. If you know of a way to do this with the webbrowser 
module I would appreciate your help. Also is there any chance that the 
ability to close browser tabs will be added to the webbrowser module soon?


Kind Regards,
James Ansell
--
https://mail.python.org/mailman/listinfo/python-list


Re: Expression can be simplified on list

2016-09-14 Thread Rustom Mody
On Wednesday, September 14, 2016 at 5:35:53 PM UTC+5:30, Jussi Piitulainen 
wrote:
> Mathematical discussions tend to acknowledge only alternation (union),
> concatenation and iteration (Kleene star) as operations, unless they
> specifically focus on some other operations that can, in principle, be
> expressed in terms of those three. There are many such.
> 
> Without further regex operations it makes sense to include a special
> regular expression that matches nothing.  Otherwise a very simple NFA
> (DFA) has no corresponding regex, which can be considered awkward.

Not sure if I parse you correct — Assuming “a very simple DFA” you mean 
“The DFA with only one state, no final state?”
If yes then yes thats the nub of the matter

More later…

[Will switch from being a CS-teacher to net-disconnected music teacher for few 
days :-) ]
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]

2016-09-14 Thread Dale Marvin via Python-list

On 9/14/16 12:20 AM, Steven D'Aprano wrote:

On Wednesday 14 September 2016 16:54, Rustom Mody wrote:


everything we know will be negated in 5-50-500 years


I'm pretty sure that in 5, 50, 500 or even 5000 years, the sun will still rise
in the east, water will be wet, fire will burn, dogs will have mammary glands
and frogs[1] won't, and the square root of 100 will still be 10.

Isaac Asimov once wrote:

When people thought the earth was flat, they were wrong. When people
thought the earth was spherical, they were wrong. But if you think that
thinking the earth is spherical is just as wrong as thinking the earth
is flat, then your view is wronger than both of them put together.



http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm

[1] Assuming that there are any frogs left by then.



Funny, Asimov's professors must have taught him the same false history 
that I was taught at college. There's much evidence that medieval 
scholars did not believe the earth was flat.




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


Re: Requests for webbrowser module

2016-09-14 Thread MRAB

On 2016-09-14 17:53, Jamie wrote:

Hi,

I am not sure if this is an intended consequence but when using the
webbrowser module to open a new blank browser tab in chrome it opens it
in a new browser window instead of using the current window. Providing
any complete url provides different behaviour, it opening a new tab in
the current browser window. Below is some code that produces the
different behaviours.

blank tab code:
import webbrowser

chrome = "C:/Program Files (x86)/Google/Chrome/Application/chrome.exe %s"
url = "chrome://newtab"
webbrowser.get(chrome).open_new_tab(url)
webbrowser.get(chrome).open_new_tab(url)

normal tab code:
import webbrowser

chrome = "C:/Program Files (x86)/Google/Chrome/Application/chrome.exe %s"
url = "http://google.com";
webbrowser.get(chrome).open_new_tab(url)
webbrowser.get(chrome).open_new_tab(url)

I would like to be able to open new blank tabs in the current browser
window if possible. If you know of a way to do this with the webbrowser
module I would appreciate your help. Also is there any chance that the
ability to close browser tabs will be added to the webbrowser module soon?


If you want a new blank tab, try giving it the URL "about:blank".

All the module does is call the browser application with the appropriate 
command line arguments, so the module could close a tab only if the 
browser itself let you do so by calling it with some argument, which 
probably won't happen...


A workaround is to select the browser window and then send it a Ctrl+F4 
keypress. Have a look at the 3rd party "pywin32" package.

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


Re: What is the correct form for saying "licensed under the same terms as Python itself"?

2016-09-14 Thread Brendan Abel
Unless you're actually distributing python (as in, the interpreter or it's
source code), you don't need to include the python license or the copyright
notice.  You also don't need a Contributor agreement just to distribute a
python library.  That is more for people who are contributing to core
Python or if your package is being added to the standard library.

Python has a custom license, though it is GPL-compatible.  The python
license has a lot of wording that is specific to python and the PSF, so it
probably doesn't make sense for you to use their license.  Also, according
to the python web site, they only accept contributions under the following
licenses:


   - Academic Free License v. 2.1
   
   - Apache License, Version 2.0
   

https://www.python.org/psf/contrib/

So, if you want your code to be available to the Python team (which is what
it sounds like), you should use one of those 2 licenses, or consider using
an even more permissive license (like the MIT license) that would not
prohibit your project from being relicensed under the Apache or Python
license.

On Wed, Sep 14, 2016 at 7:58 AM, Mark Summerfield 
wrote:

> Hi,
>
> I'm developing a small Python software library that I want to publish as
> free software under the same terms as Python itself.
>
> I notice that a few of Python's own files begin like this:
>
> # Copyright 2007 XXX. All Rights Reserved.
> # Licensed to PSF under a Contributor Agreement.
>
> Is this form sufficient?
> Do I need to include the PSF license with the package?
> (Also, I don't actually remember if I've signed a Contributor Agreement.)
>
> Thanks!
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]

2016-09-14 Thread MRAB

On 2016-09-14 18:43, Dale Marvin via Python-list wrote:

On 9/14/16 12:20 AM, Steven D'Aprano wrote:

On Wednesday 14 September 2016 16:54, Rustom Mody wrote:


everything we know will be negated in 5-50-500 years


I'm pretty sure that in 5, 50, 500 or even 5000 years, the sun will still rise
in the east, water will be wet, fire will burn, dogs will have mammary glands
and frogs[1] won't, and the square root of 100 will still be 10.

Isaac Asimov once wrote:

When people thought the earth was flat, they were wrong. When people
thought the earth was spherical, they were wrong. But if you think that
thinking the earth is spherical is just as wrong as thinking the earth
is flat, then your view is wronger than both of them put together.



http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm

[1] Assuming that there are any frogs left by then.



Funny, Asimov's professors must have taught him the same false history
that I was taught at college. There's much evidence that medieval
scholars did not believe the earth was flat.



Where does it say that he thought that _medieval_ scholars did not 
believe the earth was flat?

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


Re: Requests for webbrowser module

2016-09-14 Thread John Gordon
In  Jamie 
 writes:

> I am not sure if this is an intended consequence but when using the 
> webbrowser module to open a new blank browser tab in chrome it opens it 
> in a new browser window instead of using the current window. Providing 

There is an internal setting within Chrome that controls whether new pages
are opened in a new tab or a new window.  Perhaps that is your issue?

-- 
John Gordon   A is for Amy, who fell down the stairs
[email protected]  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

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


Re: Expression can be simplified on list

2016-09-14 Thread Terry Reedy

On 9/14/2016 3:16 AM, Rustom Mody wrote:


In THOSE TYPES that element can justifiably serve as a falsey (empty) type

However to extrapolate from here and believe that ALL TYPES can have a falsey
value meaningfully, especially in some obvious fashion, is mathematically 
nonsense.


Python make no such nonsense claim.  By default, Python objects are truthy.

>>> bool(object())
True

Because True is the default, object need not and at least in CPython 
does not have a __bool__ (or __len__) method.  Classes with no falsey 
objects, such as functions, generators, and codes, need not do anything 
either.  In the absence of an override function, the internal bool code 
returns True.


It is up to particular classes to override that default and say that it 
has one or more Falsey objects.  They do so by defining a __bool__ 
method that returns False for the falsey objects (and True otherwise) or 
by defining a __len__ method that returns int 0 for falsey objects (and 
non-0 ints otherwise).  If a class defines both, __bool__ wins.


--
Terry Jan Reedy

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


Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]

2016-09-14 Thread breamoreboy
On Wednesday, September 14, 2016 at 9:00:04 PM UTC+1, MRAB wrote:
> On 2016-09-14 18:43, Dale Marvin via Python-list wrote:
> > On 9/14/16 12:20 AM, Steven D'Aprano wrote:
> >> On Wednesday 14 September 2016 16:54, Rustom Mody wrote:
> >>
> >>> everything we know will be negated in 5-50-500 years
> >>
> >> I'm pretty sure that in 5, 50, 500 or even 5000 years, the sun will still 
> >> rise
> >> in the east, water will be wet, fire will burn, dogs will have mammary 
> >> glands
> >> and frogs[1] won't, and the square root of 100 will still be 10.
> >>
> >> Isaac Asimov once wrote:
> >>
> >> When people thought the earth was flat, they were wrong. When people
> >> thought the earth was spherical, they were wrong. But if you think that
> >> thinking the earth is spherical is just as wrong as thinking the earth
> >> is flat, then your view is wronger than both of them put together.
> >
> >> http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
> >>
> >> [1] Assuming that there are any frogs left by then.
> >>
> >
> > Funny, Asimov's professors must have taught him the same false history
> > that I was taught at college. There's much evidence that medieval
> > scholars did not believe the earth was flat.
> >
> > 
> >
> Where does it say that he thought that _medieval_ scholars did not 
> believe the earth was flat?

It is so blantantly obvious that the world is not flat I find this discussion 
flabbergasting.  Anybody who has tried to take any form of vehicle up, or 
probably more dangerously down, any form of hill knows that.  As for the raving 
lunatics who make their living by riding up and down these 
http://www.bbc.co.uk/news/in-pictures-37348004, well need I say more?

Kindest regards.

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


Re: Why don't we call the for loop what it really is, a foreach loop?

2016-09-14 Thread breamoreboy
On Tuesday, September 13, 2016 at 9:57:38 PM UTC+1, Richard Grigonis wrote:
> It would help newbies and prevent confusion.

I entirely agree.  All together now "foreach is a jolly good fellow...".

Kindest regards.

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


Re: Expression can be simplified on list

2016-09-14 Thread Terry Reedy

On 9/14/2016 8:05 AM, Jussi Piitulainen wrote:

Serhiy Storchaka writes:


On 14.09.16 11:28, Steven D'Aprano wrote:



I'm not sure if it makes sense to talk about an "empty regular
expression", or if that is the same as re.compile(''). Presumably if
such a thing makes sense, it would match nothing, from any input at
all.


Actually, it matches anything. re.compile('').match(x) returns
non-false value for any valid x.


It matches the empty string. The .match method returns a match object if
the regex matches at the start of the input. See span:

re.compile('').match('foo')
===> <_sre.SRE_Match object; span=(0, 0), match=''>

There's an empty string at every position, same content, different span:

re.compile('').findall('foo')
===> ['', '', '', '']


To put it slightly differently, regexes match slices.  A string of n 
chars has n+1 empty (len 0) slices  - the 2 at the ends and the n-1 
between chars.


--
Terry Jan Reedy

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


Re: Expression can be simplified on list

2016-09-14 Thread Lawrence D’Oliveiro
On Thursday, September 15, 2016 at 8:13:05 AM UTC+12, Terry Reedy wrote:
> Because True is the default, object need not and at least in CPython 
> does not have a __bool__ (or __len__) method.

If they had to (in the absence of which a bool() cast would not work), then 
that would help prevent problems like the one I previously linked to, don’t you 
think?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Expression can be simplified on list

2016-09-14 Thread Chris Angelico
On Thu, Sep 15, 2016 at 6:59 AM, Lawrence D’Oliveiro
 wrote:
> On Thursday, September 15, 2016 at 8:13:05 AM UTC+12, Terry Reedy wrote:
>> Because True is the default, object need not and at least in CPython
>> does not have a __bool__ (or __len__) method.
>
> If they had to (in the absence of which a bool() cast would not work), then 
> that would help prevent problems like the one I previously linked to, don’t 
> you think?
>

Nope. The problem came from a *design fault* in which times were
identified with midnight as zero, and were treated as numbers. So
whether implicit or explicit, boolification would have behaved the
same way, and the issue would have happened. I've seen very similar
issues surrounding array/list indices in various languages, and even
file descriptors (stdin is fd 0, and if you simply check the value of
the fd, stdin will appear to be false). Normally they're caught early
in design, but sometimes not. And often, particularly with student or
novice programmers, the workarounds begin looking extremely odd (why
do we start row IDs at 1, even though we have the SQL NULL value
available to mean "no ID at all"?).

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


Re: Expression can be simplified on list

2016-09-14 Thread Ned Batchelder
On Wednesday, September 14, 2016 at 5:00:02 PM UTC-4, Lawrence D’Oliveiro wrote:
> On Thursday, September 15, 2016 at 8:13:05 AM UTC+12, Terry Reedy wrote:
> > Because True is the default, object need not and at least in CPython 
> > does not have a __bool__ (or __len__) method.
> 
> If they had to (in the absence of which a bool() cast would not work), then 
> that would help prevent problems like the one I previously linked to, don’t 
> you think?

Requiring an explicit conversion method wouldn't help the "midnight is False"
problem: it was *caused* by an explicit conversion method.  From the article:

> A Python bug was opened in 2012 about midnight as False, but it was closed
> soon thereafter as "invalid". The time class was documented to work that way
> and someone had created a __nonzero__() (now __bool__()) method for time to
> implement that behavior.

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


Re: What is the correct form for saying "licensed under the same terms as Python itself"?

2016-09-14 Thread Tim Chase
On 2016-09-14 11:57, Brendan Abel wrote:
> Also, according to the python web site, they only accept
> contributions under the following licenses:
> 
>- Academic Free License v. 2.1
>
>- Apache License, Version 2.0
>
> 
> https://www.python.org/psf/contrib/
> 
> So, if you want your code to be available to the Python team (which
> is what it sounds like), you should use one of those 2 licenses, or
> consider using an even more permissive license (like the MIT
> license) that would not prohibit your project from being relicensed
> under the Apache or Python license.

In today's "questions you've wanted to ask but never got around to,
and somebody else answered them concisely even without you asking"...
I've long been curious about this, but never sufficiently to actually
go hunt down an answer.  And here it is, packaged neatly in my
inbox.  Thanks!

-tkc



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


How could I implement a virtual method and override it in python?

2016-09-14 Thread wesley . keeling
Hey guys, I will show the code first:

Helper.py:

def Foo( *args ):
print ("This is a callback")

def Run:
Foo()


MyModule.py:

import Helper

def Foo( *args ):
print ("I want to be the new callback")



I want to be able to call the Foo method in MyModule.py when it's there first 
and when it's not I want to call the Foo in helper.py. 

I am coming from .net so I am not fully understanding how the Foo method would 
override the other one. 

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


Re: Expression can be simplified on list

2016-09-14 Thread Lawrence D’Oliveiro
On Thursday, September 15, 2016 at 9:12:25 AM UTC+12, Ned Batchelder wrote:
>
> On Wednesday, September 14, 2016 at 5:00:02 PM UTC-4, Lawrence D’Oliveiro
> wrote:
>>
>> On Thursday, September 15, 2016 at 8:13:05 AM UTC+12, Terry Reedy wrote:
>>>
>>> Because True is the default, object need not and at least in CPython 
>>> does not have a __bool__ (or __len__) method.
>> 
>> If they had to (in the absence of which a bool() cast would not work),
>> then that would help prevent problems like the one I previously linked to,
>> don’t you think?
> 
> Requiring an explicit conversion method wouldn't help the "midnight is
> False" problem: it was *caused* by an explicit conversion method.

“Conversion method” versus ”explicit conversion” are two different things. The 
class provided a method to convert to bool, but Python itself does automatic 
interpretation of non-boolean values as booleans. It is the latter I am 
objecting to.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: How could I implement a virtual method and override it in python?

2016-09-14 Thread Lawrence D’Oliveiro
On Thursday, September 15, 2016 at 10:18:09 AM UTC+12, [email protected] 
wrote:
> Helper.py:
> 
> def Foo( *args ):
>   print ("This is a callback")
> 
> def Run:
> Foo()
> 
> 
> MyModule.py:
> 
> import Helper
> 
> def Foo( *args ):
>   print ("I want to be the new callback")

Overrides and subclassing applies to classes, not modules.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: How could I implement a virtual method and override it in python?

2016-09-14 Thread wesley . keeling
On Wednesday, September 14, 2016 at 3:47:52 PM UTC-7, Lawrence D’Oliveiro wrote:
> On Thursday, September 15, 2016 at 10:18:09 AM UTC+12, [email protected] 
> wrote:
> > Helper.py:
> > 
> > def Foo( *args ):
> > print ("This is a callback")
> > 
> > def Run:
> > Foo()
> > 
> > 
> > MyModule.py:
> > 
> > import Helper
> > 
> > def Foo( *args ):
> > print ("I want to be the new callback")
> 
> Overrides and subclassing applies to classes, not modules.

Yeah I assumed so, is there any ways I can get this to work with the importing 
of the helper?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]

2016-09-14 Thread Steve D'Aprano
On Thu, 15 Sep 2016 03:43 am, Dale Marvin wrote:

> On 9/14/16 12:20 AM, Steven D'Aprano wrote:
>> On Wednesday 14 September 2016 16:54, Rustom Mody wrote:
>>
>>> everything we know will be negated in 5-50-500 years
>>
>> I'm pretty sure that in 5, 50, 500 or even 5000 years, the sun will still
>> rise in the east, water will be wet, fire will burn, dogs will have
>> mammary glands and frogs[1] won't, and the square root of 100 will still
>> be 10.
>>
>> Isaac Asimov once wrote:
>>
>> When people thought the earth was flat, they were wrong. When people
>> thought the earth was spherical, they were wrong. But if you think
>> that thinking the earth is spherical is just as wrong as thinking the
>> earth is flat, then your view is wronger than both of them put
>> together.
> 
>> http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
>>
>> [1] Assuming that there are any frogs left by then.
>>
> 
> Funny, Asimov's professors must have taught him the same false history
> that I was taught at college. There's much evidence that medieval
> scholars did not believe the earth was flat.

I don't see Asimov referring to medieval scholars. The medieval period is
roughly around 1000 CE or thereabouts. Asimov talks about people believing
in a flat earth "In the early days of civilization" and goes on to discuss
how Greeks such as Aristotle (350 BCE) had evidence for a spherical earth.
He doesn't mention the medieval period at all.

If you're going to criticise Asimov, don't criticise him for wrongly
thinking that people in the Middle Ages believed in a flat earth. There's
no evidence of that in his essay.

Rather, criticise him for over-simplifying how quickly and universally the
idea of the spherical earth took over. Asimov jumps from Eratosthenes
(about a century after Aristotle, so around 250 BCE) to Newton (17th
century) with nary a mention of how long, slow and difficult it was for the
flat earth cosmology to be discarded. Regardless of what a few ivory-tower
Greek philosophers thought, in the early centuries CE many people still
believed the world was flat.

While it is true that by the Middle Ages educated scholars in Europe almost
certainly believed in a spherical world, not all people were educated
scholars. We have no idea what the average peasant tilling the fields would
have believed, although given the influence of Christianity and the
remnants of ancient Hebrew cosmology (flat earth) in the Bible, it is far
more likely that the average uneducated person believed in a flat earth.
But we don't really know for sure.

And there is more to the world than just Europe. In China, belief in a flat
earth cosmology was virtually unchallenged until the 17th century.

https://en.wikipedia.org/wiki/Flat_Earth




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]

2016-09-14 Thread Steve D'Aprano
On Thu, 15 Sep 2016 06:19 am, [email protected] wrote:

> It is so blantantly obvious that the world is not flat I find this
> discussion flabbergasting.

You wouldn't say that if you lived in Kanvas, or the west coast of Ireland.

I'm told that a few years ago somebody accidentally dumped a trailer load of
soil by the side of the road in Kanvas, and within a day some enterprising
entrepreneur had set up a thriving roadside business offering
mountain-climbing tours to the locals.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: How could I implement a virtual method and override it in python?

2016-09-14 Thread Steve D'Aprano
On Thu, 15 Sep 2016 08:16 am, [email protected] wrote:

> Hey guys, I will show the code first:
> 
> Helper.py:
> 
> def Foo( *args ):
> print ("This is a callback")
> 
> def Run:
> Foo()
> 
> 
> MyModule.py:
> 
> import Helper
> 
> def Foo( *args ):
> print ("I want to be the new callback")
> 
> 
> 
> I want to be able to call the Foo method in MyModule.py when it's there
> first and when it's not I want to call the Foo in helper.py.

What is doing the calling?

Surely MyModule knows whether or not it has a Foo function? Or rather, the
author of MyModule knows whether or not he has defined a Foo function.

I don't understand how this problem would come about in practice. If you are
writing MyModule, you surely must know whether or not you have defined Foo.
If you have, you call

Foo()


and if you haven't, you write:

from Helper import Foo
Foo()

or perhaps:

import Helper
Helper.Foo()


If for some reason you won't know until runtime whether or not Foo exists,
you can say:


try:
Foo  # don't call the function, just name it
except NameError:
# Doesn't exist, so use the helper function
from Helper import Foo

Foo()  # works either way now



If it is a *third* module doing the calling, then things start to be a bit
more clear. So I have my main application, and I want to use a function Foo
defined in MyModule, if it exists, otherwise Foo defined in Helper.

Here is one way to do it:


# main.py
try:
from MyModule import Foo
except ImportError:
from Helper import Foo

Foo()




> I am coming from .net so I am not fully understanding how the Foo method
> would override the other one.

It doesn't.

Perhaps you are unclear about the difference between methods of a class and
functions in modules?




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]

2016-09-14 Thread Chris Kaynor
On Wed, Sep 14, 2016 at 1:19 PM,  wrote:

> It is so blantantly obvious that the world is not flat I find this
> discussion flabbergasting.  Anybody who has tried to take any form of
> vehicle up, or probably more dangerously down, any form of hill knows
> that.  As for the raving lunatics who make their living by riding up and
> down these http://www.bbc.co.uk/news/in-pictures-37348004, well need I
> say more?
>

Going up or down a mountain does not prove the world is round by itself, no
matter how twisted the road might be. Take for example most 3D game worlds,
which are generally simulated using a flat-world for ease, but still
simulate gravity (and sometimes even the horizon) just fine.

If you find somebody determined to not trust evidence such as the blue
marble photos, it can be quite hard to prove that the world is not flat.
The major issue comes from the fact that, at a human scale, the difference
between a flat world and and Earth is very small - you don't need to take
into account the curve of the earth for almost any buildings.

With that in mind, I'm not sure what evidence you claim is "blatantly
obvious". By far the two simplest evidence is traveling around the Earth
(not particularly easy, especially even 100 years ago) and watching the
stars move. Both could be explained by other methods, but those would be
vastly more complicated to explain the observed behavior (look at the
Earth-centric universe models).

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


Creating A Pythonic ctypes Binding

2016-09-14 Thread Lawrence D’Oliveiro
ctypes  is a wonderful
library. If you need to create a Python binding for some library that
doesn’t already have one, you should look at ctypes, rather than
writing an extension module in C or C++. The odds are, a pure Python
implementation using ctypes can be done with much less effort than
writing C/C++ code.

But it is not enough to wrap an API designed for C or C++. A Python
API should take advantage of the power and convenience of Python. The
question I like to ask is: “How would the API have been designed if it
was native to Python, rather than being intended for C or C++?”.
Another question to consider is: “Does the Python API binding give you
a reason to use Python to write your code in the first place, rather
than choosing C or C++ instead?”. In short, does your Python code that
makes calls to the API look like a straight transliteration of C code,
or does it work at a higher level?

What do I mean by this? An obvious, very basic, example is not having
the user have to bother with explicitly creating and destroying
objects. Wrap an underlying API object in a Python object, such that
the Python object’s “__del__” method will take care of disposing of
the API object. Then Python’s usual object-management mechanisms will
automatically manage the API objects as well. This is how Qahirah
, my wrapper for the Cairo graphics
library , works.

But there is more you can do. Another obvious one is, where the
underlying API provides “get_xxx” and “set_xxx” methods, to wrap them
in a read/write Python property.

For example, Cairo defines a “fill rule” that governs how paths are
filled, with getter and setter calls
.
In Qahirah this is translated to a property that you can obtain with a
simple expression like “«ctx».fill_rule” (where «ctx» is a Context
object), and change by a simple assignment like “«ctx».fill_rule =
«new_value»”.

Sometimes the values that are returned by the getter or set with the
setter have a more complex, variable-length structure. So the C API
may need two parts to the getter routines, one to determine how big a
structure the caller needs to allocate, and the other to fill in a
preallocated structure with the actual data. For example, the dash
setting for stroking lines

is of this type.

In Python, it makes sense to store the dash information in a
high-level Python object, which is directly returned from the
Python-level getter and directly passed to the Python-level setter. In
Qahirah, I use a 2-tuple, the first element of which specifies the
alternating on/off dash lengths (itself a tuple), and the second of
which is the starting offset. All conversion between this format and
the actual format that Cairo expects happens within the Python wrapper
routines, without the caller having to worry about it.

Sometimes the opportunities to add value come from other available
Python libraries. Cairo only deals with colours as RGB components,
with an optional alpha. But Python provides this handy colorsys module
 as standard, which
provides conversions to/from a number of non-RGB colour spaces; why
not take advantage of it?

So I defined a “Colour” type, and all wrappers to Cairo calls that set
or get colours take or return this object instead of separate RGB or
RGBA components. A Colour can be constructed from components in any of
the supported colour spaces, and you can query its components in any
of these colour spaces.

But more than that, you can also perform useful manipulations on
Colours, like adjusting the values of components to produce new, but
related, colours. This all goes way beyond the functionality of Cairo
itself, but I felt it was useful, even essential, to have in a
worthwhile graphics API.

Python has a remarkably simple and elegant technique for implementing
custom overloading of its standard operators. C, of course, has no
such thing. So APIs designed for C have to provide function calls
instead, such as for Cairo’s matrix operations
.

It was easy enough for me to define a “Matrix” class, with the “*”
operator (“@” as well in Python 3.5 or later) to do Matrix
multiplication. Instead of updating a Matrix object in place
(procedural programming), I prefer a more functional approach, where
each operation creates a new Matrix object as its result, leaving its
operands unchanged. This lets you write expressions which are closer
to the underlying mathematics.

I also defined a “Vector” class, representing both X and Y coordinates
in a single value. Cairo itself requires you to pass (or get back)
separate X and Y coordinate values; but again, I wrap all these calls
so that you pass and return Vectors. It is ex

Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]

2016-09-14 Thread Lawrence D’Oliveiro
On Thursday, September 15, 2016 at 1:26:49 PM UTC+12, Chris Kaynor wrote:
> If you find somebody determined to not trust evidence such as the blue
> marble photos, it can be quite hard to prove that the world is not flat.

A flat world doesn’t have a horizon.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]

2016-09-14 Thread Steve D'Aprano
On Thu, 15 Sep 2016 11:44 am, Lawrence D’Oliveiro wrote:

> On Thursday, September 15, 2016 at 1:26:49 PM UTC+12, Chris Kaynor wrote:
>> If you find somebody determined to not trust evidence such as the blue
>> marble photos, it can be quite hard to prove that the world is not flat.
> 
> A flat world doesn’t have a horizon.


Yes it does. Even an infinitely large flat plane has a horizon almost
identical to the actual horizon.

http://www.askamathematician.com/2012/08/q-if-earth-was-flat-would-there-be-the-horizon-if-so-what-would-it-look-like-if-the-earth-was-flat-and-had-infinite-area-would-that-change-the-answer/

http://boards.straightdope.com/sdmb/showthread.php?t=385334



In fact, Flat Earthers consider the flat horizon evidence for a flat Earth:

http://www.atlanteanconspiracy.com/2015/01/flat-earth-horizon.html


Relevant:

https://www.lhup.edu/~dsimanek/flat/flateart.htm





(To answer my rhetorical question in the subject header: yes, apparently we
can.)



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: Expression can be simplified on list

2016-09-14 Thread Steve D'Aprano
On Thu, 15 Sep 2016 08:46 am, Lawrence D’Oliveiro wrote:

> On Thursday, September 15, 2016 at 9:12:25 AM UTC+12, Ned Batchelder
> wrote:
>>
>> On Wednesday, September 14, 2016 at 5:00:02 PM UTC-4, Lawrence D’Oliveiro
>> wrote:
>>>
>>> On Thursday, September 15, 2016 at 8:13:05 AM UTC+12, Terry Reedy wrote:

 Because True is the default, object need not and at least in CPython
 does not have a __bool__ (or __len__) method.
>>> 
>>> If they had to (in the absence of which a bool() cast would not work),
>>> then that would help prevent problems like the one I previously linked
>>> to, don’t you think?
>> 
>> Requiring an explicit conversion method wouldn't help the "midnight is
>> False" problem: it was *caused* by an explicit conversion method.
> 
> “Conversion method” versus ”explicit conversion” are two different things.
> The class provided a method to convert to bool, but Python itself does
> automatic interpretation of non-boolean values as booleans. It is the
> latter I am objecting to.

So you have made clear, but what isn't clear is what is the reason for the
objection. Is it just a matter of taste?

If not, can you explain what *objective* reasons you have for preferring the
second over the first. Try to be explicit, rather than just dropping hints
and pretending that it is self-evident and obvious.


if obj: ...
# implicitly calls obj.__bool__ or equivalent, by the bool protocol

# versus

if bool(obj): ...
# implicitly calls obj.__bool__ or equivalent



Apart from the extra six characters, I see no difference. What am I missing?





-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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


Re: Expression can be simplified on list

2016-09-14 Thread Jussi Piitulainen
Rustom Mody writes:

> On Wednesday, September 14, 2016 at 5:35:53 PM UTC+5:30, Jussi Piitulainen 
> wrote:

>> Mathematical discussions tend to acknowledge only alternation
>> (union), concatenation and iteration (Kleene star) as operations,
>> unless they specifically focus on some other operations that can, in
>> principle, be expressed in terms of those three. There are many such.
>> 
>> Without further regex operations it makes sense to include a special
>> regular expression that matches nothing.  Otherwise a very simple NFA
>> (DFA) has no corresponding regex, which can be considered awkward.
>
> Not sure if I parse you correct — Assuming “a very simple DFA” you
> mean “The DFA with only one state, no final state?”

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


Re: Why don't we call the for loop what it really is, a foreach loop?

2016-09-14 Thread Travis Griggs


> On Sep 13, 2016, at 13:57, [email protected] wrote:
> 
> It would help newbies and prevent confusion.

for each in ['cake'] + ['eat', 'it'] * 2:
print(each)


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


unexpected rerun program itself when using cv2 and selenium

2016-09-14 Thread meInvent bbird
unexpected rerun program itself when using cv2 and selenium

when a script, it is expected to run once and stop
but it start a new browser again when using selenium and cv2


d, bbox, filename)
  File "C:\Python27\lib\site-packages\pyscreenshot\procutil.py", line 28, in run
_in_childprocess
p.start()
  File "C:\Python27\lib\multiprocessing\process.py", line 130, in start
self._popen = Popen(self)
  File "C:\Python27\lib\multiprocessing\forking.py", line 258, in __init__
cmd = get_command_line() + [rhandle]
  File "C:\Python27\lib\multiprocessing\forking.py", line 358, in get_command_li
ne
is not going to be frozen to produce a Windows executable.''')
RuntimeError:
Attempt to start a new process before the current process
has finished its bootstrapping phase.

This probably means that you are on Windows and you have
forgotten to use the proper idiom in the main module:

if __name__ == '__main__':
freeze_support()
...

The "freeze_support()" line can be omitted if the program
is not going to be frozen to produce a Windows executable.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Why don't we call the for loop what it really is, a foreach loop?

2016-09-14 Thread Paul Rubin
Travis Griggs  writes:
> for each in ['cake'] + ['eat', 'it'] * 2:
> print(each)

https://pbs.twimg.com/media/Cr-edT2VUAArpVL.jpg
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Why don't we call the for loop what it really is, a foreach loop?

2016-09-14 Thread Christian Gollwitzer

Am 15.09.16 um 07:01 schrieb Paul Rubin:

Travis Griggs  writes:

for each in ['cake'] + ['eat', 'it'] * 2:
print(each)


https://pbs.twimg.com/media/Cr-edT2VUAArpVL.jpg


http://www.azlyrics.com/lyrics/queen/bohemianrhapsody.html

More interestingly, which language is it? First I thought C++ or Java, 
but they don't use self and there is a => operator. PHP adornes 
variables with $. Another C-derived language which has built-in hash maps?


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


Re: Why don't we call the for loop what it really is, a foreach loop?

2016-09-14 Thread Marko Rauhamaa
Christian Gollwitzer :

> More interestingly, which language is it? First I thought C++ or Java,
> but they don't use self and there is a => operator. PHP adornes
> variables with $. Another C-derived language which has built-in hash
> maps?

C#. The => syntax is Python's lambda.


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


Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]

2016-09-14 Thread Random832
On Wed, Sep 14, 2016, at 23:12, Steve D'Aprano wrote:
> Yes it does. Even an infinitely large flat plane has a horizon almost
> identical to the actual horizon.

Your link actually doesn't support the latter claim, it goes into some
detail on why it wouldn't if it were infinitely large due to
gravitational effects on light.

Of course, the fact that the horizon is a short [in comparison to the
size of the known world] distance away *is* evidence for a round Earth.
It might "look the same", but it would contain features all the way up
to potentially the edge (anything not obstructed by subjectively taller
objects in front of it), it certainly wouldn't make sense not to see the
opposing landmass across an ocean.

> http://www.askamathematician.com/2012/08/q-if-earth-was-flat-would-there-be-the-horizon-if-so-what-would-it-look-like-if-the-earth-was-flat-and-had-infinite-area-would-that-change-the-answer/
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What is the correct form for saying "licensed under the same terms as Python itself"?

2016-09-14 Thread Mark Summerfield
Thanks v. much: I'll use the Apache 2.0 license.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Why don't we call the for loop what it really is, a foreach loop?

2016-09-14 Thread Paul Rubin
Christian Gollwitzer  writes:
> http://www.azlyrics.com/lyrics/queen/bohemianrhapsody.html

Alt version, https://www.youtube.com/watch?v=hpvlTVgeivU
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]

2016-09-14 Thread Dale Marvin via Python-list

On 9/14/16 5:40 PM, Steve D'Aprano wrote:


If you're going to criticise Asimov, don't criticise him for wrongly
thinking that people in the Middle Ages believed in a flat earth. There's
no evidence of that in his essay.



I didn't mean to criticize Asimov, but the History Professors, one in 
particular seemed to make it his life's purpose to say bad things about 
religion/bible etc.


I should have known better than to get into such an off-topic quagmire.

Dale

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


Re: [RELEASE] Python 3.6.0b1 is now available

2016-09-14 Thread Serhiy Storchaka

On 14.09.16 17:36, Guido van Rossum wrote:

Fortunately that page isn't linked from anywhere on the home page
AFAIK. If it is, could someone file an issue in the pydotorg tracker?
The url is at the bottom of every page.


This is on of the first results (actually the first besides manually 
edited news) of googling "python news".



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