Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]

[Rustom Mody]

On Thursday, March 5, 2015 at 10:49:54 AM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody:
> 
> > You keep talking of accent.
> > At first I thought you were using the word figuratively or else joking.
> > Im now beginning to wonder if you mean it literally.
> > If so have you patented a new AOIP protocol?
> > If not do you give tuitions¹ in ESP/telepathy/Voodoo? I'll be happy to
> > pay
> 
> Where I work, people do use voice still occasionally to communicate.

I really dont understand what we are communicating (or not) about...

Can you hear my accent? I certainly cant hear yours
If you are talking of accent (aural/physical just to be clear) of your 
co-workers
how is that more on-topic or relevant to this list than the weather in Finland.
[Yeah its been freakish weather out here for the last 10 days -- global warming?
And is global warming on topic for this list?]
Just to be clear -- I am going to be one of the tail-enders complaining about
on/off-topicness.  But someone or other will complain I guess.

If on the other hand you are being slightly metaphorical and using 'accent'
to talk of (say) Mark's britishisms¹ then please disambiguate for better 
communication.

But more to the point its still not clear (to me) whether you are objecting to
- to Mark
- to British accent
- to British spellings in software
- to anyone/anywhere international, using non-international format


¹Personally I find Mark's britishisms sometimes funny eg I found this
 https://groups.google.com/d/msg/comp.lang.python/EfloMHB3DjQ/ZdY3Vn_6rpsJ 
hilarious even though I could not decipher more than 70% of the british accent.
Sometimes though I find it irrelevant/unnecessary/undecipherable.

Personally I am not going to object to him nor am I going to object to anyone 
objecting to him.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Speeding up permutations generation

[Ian Kelly]

On Thu, Mar 5, 2015 at 11:44 PM, Abhiram R  wrote:
> Hi all,
> Is there a way to generate permutations of large arrays of sizes say,in the
> hundreds, faster than in the time itertools.permutations() can return?

A list of 100 elements has approximately 9.33 x 10**157 permutations.
If you could somehow generate one permutation every yoctosecond,
exhausting them would still take more than a hundred orders of
magnitude longer than the age of the universe.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How fast does your grass grow? [was Re: HELP!! How to ask a girl out with a simple witty Python code??]

[Chris Angelico]

On Fri, Mar 6, 2015 at 2:48 PM, Ethan Furman  wrote:
> On 03/05/2015 07:37 PM, Chris Angelico wrote:
>
>> I'm sure there's something more interesting to talk about... like the
>> rate at which the grass is growing.
>
> My grass doesn't grow -- I ripped it all out and put down pea-gravel and 
> planter boxes.
>
> Oh, wait, I have some bamboo in the back -- that's a grass, isn't it?  Hmmm, 
> well, it grows fast enough that my dogs
> haven't managed to eat it gone yet.  :)

Our grass is actually growing at the moment, which is unusual for
Australia at this time of year. Usually it's in a state of bronzing
part way through December, and basically stays that way until well
into February.

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

Re: Make standalone gui-enabled app for LINUX

[Mehdi]

I have no experience with pyqt and so pyqtdeploy but it seems what i need.

> I haven't announced this on the list yet, but... 
> 
> http://pyqt.sourceforge.net/Docs/pyqtdeploy/ 
> 
> Phil 

But i think pyinstaller doesn't work with python3.

On Friday, March 6, 2015 at 12:58:11 AM UTC+3:30, Christian Gollwitzer wrote:
> Use pyinstaller. It creates a "portable app", i.e. either single file or
> directory which can be run on (nearly) any system. However the resulting
> files can be awfully big. I use it with a relatively small program that
> depends on numpy/matplolib, and that pulls in ~100 MB worth of libraries.
> 
>   Christian
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Speeding up permutations generation

[Abhiram R]

>
> A list of 100 elements has approximately 9.33 x 10**157 permutations.
> If you could somehow generate one permutation every yoctosecond,
> exhausting them would still take more than a hundred orders of
> magnitude longer than the age of the universe.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

​True that :D I may have exaggerated on the number. Let's consider
something more practically manageable​ => 50 elements with a 50!
permutation.
Is there a solution now?


​-Abhiram.R
*~Never give up*
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]

[Mark Lawrence]

On 06/03/2015 08:00, Rustom Mody wrote:

On Thursday, March 5, 2015 at 10:49:54 AM UTC+5:30, Marko Rauhamaa wrote:

Rustom Mody:


You keep talking of accent.
At first I thought you were using the word figuratively or else joking.
Im now beginning to wonder if you mean it literally.
If so have you patented a new AOIP protocol?
If not do you give tuitions¹ in ESP/telepathy/Voodoo? I'll be happy to
pay


Where I work, people do use voice still occasionally to communicate.


I really dont understand what we are communicating (or not) about...

Can you hear my accent? I certainly cant hear yours
If you are talking of accent (aural/physical just to be clear) of your 
co-workers
how is that more on-topic or relevant to this list than the weather in Finland.
[Yeah its been freakish weather out here for the last 10 days -- global warming?
And is global warming on topic for this list?]
Just to be clear -- I am going to be one of the tail-enders complaining about
on/off-topicness.  But someone or other will complain I guess.

If on the other hand you are being slightly metaphorical and using 'accent'
to talk of (say) Mark's britishisms¹ then please disambiguate for better 
communication.

But more to the point its still not clear (to me) whether you are objecting to
- to Mark
- to British accent


British accent, Christmas is early this year so ho, ho, ho.  Nobody in 
this country ever guesses where I was born and bred, they all think I'm 
from the South West or the West Country.  Irish, Scottish, Welsh, 
English alone are different.  Most foreigners wouldn't have a dog's 
chance in hell of understanding a Geordie or a Glaswegian.  Move 50 
miles and you can hear a completely different accent.  British accent 
indeed.



- to British spellings in software
- to anyone/anywhere international, using non-international format


¹Personally I find Mark's britishisms sometimes funny eg I found this
  https://groups.google.com/d/msg/comp.lang.python/EfloMHB3DjQ/ZdY3Vn_6rpsJ 
hilarious even though I could not decipher more than 70% of the british accent.
Sometimes though I find it irrelevant/unnecessary/undecipherable.

Personally I am not going to object to him nor am I going to object to anyone
objecting to him.



Anybody objecting about me will be accused by me of discrimination 
against autistic people.  Now there is a not very subtle hint that might 
penetrate one or two of the thicker skins on the thicker heads that 
participate here.  Thankfully the numbers of such people are extremely 
small or we could have had WWIII.  Which could have happened when Global 
Crossing bought Racal Telecommunications and tried to stop us Brits 
using our kettles to make our cuppas.  Now that is seriously brain dead. 
 And they turned out to be a bit naughty with the books :(


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Speeding up permutations generation

[Mark Lawrence]

On 06/03/2015 06:44, Abhiram R wrote:

Hi all,
Is there a way to generate permutations of large arrays of sizes say,in
the hundreds, faster than in the time itertools.permutations() can return?

​-Abhiram.R
/~Never give up/



If there is I'd guess that you'd use numpy http://www.numpy.org/.  The 
more mathematically minded may well be able to give better answers.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Speeding up permutations generation

[Wolfgang Maier]

On 03/06/2015 09:34 AM, Mark Lawrence wrote:

On 06/03/2015 06:44, Abhiram R wrote:

Hi all,
Is there a way to generate permutations of large arrays of sizes say,in
the hundreds, faster than in the time itertools.permutations() can
return?

​-Abhiram.R
/~Never give up/



If there is I'd guess that you'd use numpy http://www.numpy.org/.  The
more mathematically minded may well be able to give better answers.



Well, numpy would be faster if you could call into it once and retrieve 
all permutations as an array. This would allow you to do all 
calculations in C, while itertools.permutations has to jump back and 
forth between C and Pyhon code.


However, 50! is still ~ 3*10^64. So where would you want to store the 
array of these many permutations ?


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

Re: Newbie question about text encoding

[Rustom Mody]

On Friday, March 6, 2015 at 10:50:35 AM UTC+5:30, Chris Angelico wrote:
> On Fri, Mar 6, 2015 at 3:53 PM, Rustom Mody wrote:
> > My conclusion: Early adopters of unicode -- Windows and Java -- were 
> > punished
> > for their early adoption.  You can blame the unicode consortium, you can
> > blame the babel of human languages, particularly that some use characters
> > and some only (the equivalent of) what we call words.
> >
> > Or you can skip the blame-game and simply note the fact that large segments 
> > of
> > extant code-bases are currently in bug-prone or plain buggy state.
> 
> For most of the 1990s, I was writing code in REXX, on OS/2. An even
> earlier adopter, REXX didn't have Unicode support _at all_, but
> instead had facilities for working with DBCS strings. You can't get
> everything right AND be the first to produce anything. Python didn't
> make Unicode strings the default until 3.0, but that's not Unicode's
> fault.
> 
> > This includes not just bug-prone-system code such as Java and Windows but
> > seemingly working code such as python 3.
> >
> > Here is Roy's Smith post that first started me thinking that something may
> > be wrong with SMP
> > https://groups.google.com/d/msg/comp.lang.python/loYWMJnPtos/GHMC0cX_hfgJ
> >
> > Some parts are here some earlier and from my memory.
> > If details wrong please correct:
> > - 200 million records
> > - Containing 4 strings with SMP characters
> > - System made with python and mysql. SMP works with python, breaks mysql.
> >   So whole system broke due to those 4 in 200,000,000 records
> >
> > I know enough (or not enough) of unicode to be chary of statistical 
> > conclusions
> > from the above.
> > My conclusion is essentially an 'existence-proof':
> 
> Hang on hang on. Why are you blaming Python or SMP characters for
> this? The problem here is MySQL, which doesn't adequately cope with
> the full Unicode range. (Or, didn't then, or doesn't with its default
> settings. I believe you can configure current versions of MySQL to
> work correctly, though I haven't actually checked. PostgreSQL gets it
> right, that's good enough for me.)
> 
> > SMP-chars can break systems.
> > The breakage is costly-fied by the combination
> > - layman statistical assumptions
> > - BMP → SMP exercises different code-paths
> 
> Broken systems can be shown up by anything. Suppose you have a program
> that breaks when it gets a NUL character (not unknown in C code); is
> the fault with the Unicode consortium for allocating something at
> codepoint 0, or the code that can't cope with a perfectly normal
> character?

Strawman.

Lets please stick to UTF-16 shall we?

Now tell me:
- Is it broken or not?
- Is it widely used or not?
- Should programmers be careful of it or not?
- Should programmers be warned about it or not?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie question about text encoding

[Rustom Mody]

On Friday, March 6, 2015 at 2:33:11 PM UTC+5:30, Rustom Mody wrote:
> Lets please stick to UTF-16 shall we?
> 
> Now tell me:
> - Is it broken or not?
> - Is it widely used or not?
> - Should programmers be careful of it or not?
> - Should programmers be warned about it or not?

Also:
Can a programmer who is away from UTF-16 in one part of the system (say by 
using python3)
assume he is safe all over?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie question about text encoding

[Chris Angelico]

On Fri, Mar 6, 2015 at 8:02 PM, Rustom Mody  wrote:
>> Broken systems can be shown up by anything. Suppose you have a program
>> that breaks when it gets a NUL character (not unknown in C code); is
>> the fault with the Unicode consortium for allocating something at
>> codepoint 0, or the code that can't cope with a perfectly normal
>> character?
>
> Strawman.

Not really, no. I know of lots of programs that can't handle embedded
NULs, and which fail in various ways when given them (the most common
is simple truncation, but it's by far not the only way). And it's
exactly the same: a program that purports to handle arbitrary Unicode
text should be able to handle arbitrary Unicode text, not "Unicode
text as long as it contains only codepoints within the range X-Y". It
doesn't matter whether the code chokes on U+, U+005C, U+FFFC, or
U+1F4A3 - if your code blows up, it's a failure in your code.

> Lets please stick to UTF-16 shall we?
>
> Now tell me:
> - Is it broken or not?
> - Is it widely used or not?
> - Should programmers be careful of it or not?
> - Should programmers be warned about it or not?

No, UTF-16 is not itself broken. (It would be if we expected
codepoints >0x10, and it's because of UTF-16 that that's the cap
on Unicode, but it's looking unlikely that we'll be needing any more
than that anyway.) What's broken is code that tries to treat UTF-16 as
if it's UCS-2, and then breaks on surrogate pairs.

Yes, it's widely used. Programmers should probably be warned about it,
but only because its tradeoffs are generally poorer than UTF-8's. If
you use it correctly, there's no problem.

> Also:
> Can a programmer who is away from UTF-16 in one part of the system (say by 
> using python3)
> assume he is safe all over?

I don't know what you mean here. Do you mean that your Python 3
program is "at risk" in some way because there might be some other
program that misuses UTF-16? Well, sure. And there might be some other
program that misuses buffer sizes, SQL queries, or shell invocations,
and makes your overall system vulnerable to buffer overruns or
injection attacks. These are significantly more likely AND more
serious than UTF-16 misuses. And you still have not proven anything
about SMP characters being a problem, but only that code can be
broken. Broken code is still broken code, no matter what your actual
brokenness.

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

Re: Is nan in (nan,) correct?

[Rustom Mody]

On Friday, March 6, 2015 at 3:57:12 AM UTC+5:30, rand...@fastmail.us wrote:
> It's been brought up on Stack Overflow that the "in" operator (on
> tuples, and by my testing on dict and list, as well as dict lookup) uses
> object identity as a shortcut, and returns true immediately if the
> object being tested *is* an element of the container. However, the
> contains operation does not specify whether object identity or equality
> is to be used. In effect, the built-in container types use a hybrid
> test: "a is b or a == b".
> 
> My question is, is this a *correct* implementation of the operator, or
> are objects "supposed to" use a basis of equality for these tests?

nan is an illegal or bogus value.
As usual legalizing the illegal is always fraught with increasing conundrums.

The most (to me) classic instance of this is denotational semantics.
In DS one tries to give semantics to programs by mapping programs to 
math-functions across some domains

However some programs crash. What should be the semantics of such a program.
We say its a partial function – undefined at the crash-points.
But partial functions are not nearly as tractable (to mathematicians!) as total
functions. 
So we invent a bogus value  ⊥ (called bottom) and totalize all functions by
mapping to this.

Very nice…

So nice in fact that we wish to add ⊥ to our programming language

And now all hell breaks loose because the question x == ⊥ is the halting 
problem.

And people love this problem so much they keep replicating it:

- C and null (or Pascal/Lisp and Nil)
[Hoare's billion dollar mistake 
https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions ]
- nul in SQL – Should two nuls compare as same or different?
  There are good (and different!) reasons for both answers
- Python and None
- Floats and nans

My own thoughts on this (not very well thought out, I admit)
The letter of the IEEE standard talks of nans and their details
The spirit of the standard is that nans capture exception-al computations
ie nan represents an exception

In a language like python with decent exceptions we do not need nans.

Of course there are all sorts of corner cases eg data source is something 
outside python etc
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Speeding up permutations generation

[Chris Angelico]

On Fri, Mar 6, 2015 at 7:24 PM, Abhiram R  wrote:
>> A list of 100 elements has approximately 9.33 x 10**157 permutations.
>> If you could somehow generate one permutation every yoctosecond,
>> exhausting them would still take more than a hundred orders of
>> magnitude longer than the age of the universe.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>
>
> True that :D I may have exaggerated on the number. Let's consider something
> more practically manageable => 50 elements with a 50! permutation.
> Is there a solution now?
>

Is the actual generation of permutations your problem? You mentioned
that you're using itertools, so I would expect that you're simply
iterating over that; I hope you're not immediately trying to construct
a list of them all, because that would cost the memory that Mark's
response talks about. Have you actually profiled your code and found
that generating permutations is the bottleneck, or did you just guess?
Because even experienced programmers - even extremely experienced
Python programmers - are usually wrong when they guess about the
slowest part of a program. The only way to know is to measure.

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

Re: Is nan in (nan,) correct?

[Chris Angelico]

On Fri, Mar 6, 2015 at 8:50 PM, Rustom Mody  wrote:
> In a language like python with decent exceptions we do not need nans.

Not so. I could perhaps accept that we don't need signalling NaNs, as
they can be replaced with exceptions, but quiet NaNs are by definition
_not_ exceptions.

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

Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]

[Marko Rauhamaa]

Rustom Mody :

> I really dont understand what we are communicating (or not) about...
>
> Can you hear my accent?

If we met at a Python conference, I would hear it and hopefully even
understand it.

> But more to the point its still not clear (to me) whether you are objecting to
> - to Mark
> - to British accent
> - to British spellings in software
> - to anyone/anywhere international, using non-international format

I'm objecting (mildly) to British spellings in source code and technical
documentation.

I'm objecting (more strongly) to local English accents in settings
including but not limited to:

 - conference speeches with international audiences

 - group discussions with international participants

 - teleconferences with international participants

In my experience, it is harder to understand most British English
accents than, say, a run-of-the-mill Chinese engineer trying to speak
English. It has to do with pronunciation, speed and eloquence (too much
of it with native speakers).


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

Re: Python Worst Practices

[Chris Angelico]

On Fri, Mar 6, 2015 at 5:58 PM, Jonas Wielicki  wrote:
> On 01.03.2015 03:43, Chris Angelico wrote:
>> Imagine if all
>> your Python code ran twice as fast (that's slightly better than the
>> IronPython figure quoted!), but worked only on BSD Unix and Mac OS. Is
>> that something that'll make a fledgling language succeed?
>
> I heard that Swift and Objective-C are quite popular these days.
>
> regards,
> jwi

In other words, it requires major pushing from the platform vendor.
It'd be impossible for some third-party to make a language that
successful, I expect. And even *with* that kind of pushing, it's
pretty chancy; there was a time (maybe times, I don't remember) when
Microsoft tried hard to require "managed code" everywhere (aka ".NET
runtime only"), and the push-back was so strong that they had to
abandon the requirement. But somehow, people accept rules about phone
apps that they wouldn't accept about desktop apps... crazy stuff.

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

Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]

[Marko Rauhamaa]

Mark Lawrence :

> British accent, Christmas is early this year so ho, ho, ho. Nobody in
> this country ever guesses where I was born and bred, they all think
> I'm from the South West or the West Country. Irish, Scottish, Welsh,
> English alone are different. Most foreigners wouldn't have a dog's
> chance in hell of understanding a Geordie or a Glaswegian. Move 50
> miles and you can hear a completely different accent. British accent
> indeed.

The accents on the British isles are indeed much more diverse than in
the colonies. They can also be very hard to understand, sometimes for
native English-speakers as well.


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

Re: Newbie question about text encoding

[Rustom Mody]

On Friday, March 6, 2015 at 3:24:48 PM UTC+5:30, Chris Angelico wrote:
> On Fri, Mar 6, 2015 at 8:02 PM, Rustom Mody wrote:
> >> Broken systems can be shown up by anything. Suppose you have a program
> >> that breaks when it gets a NUL character (not unknown in C code); is
> >> the fault with the Unicode consortium for allocating something at
> >> codepoint 0, or the code that can't cope with a perfectly normal
> >> character?
> >
> > Strawman.
> 
> Not really, no. I know of lots of programs that can't handle embedded
> NULs, and which fail in various ways when given them (the most common
> is simple truncation, but it's by far not the only way).

Ah well if you insist on pursuing the nul-char example...
No the unicode consortium (or ASCII equivalent) is not wrong in allocating 
codepoint 0
Nor the code that "can't cope with a perfectly normal character?"

But with C for having a data structure called string with a 'hole' in it.

And it's
> exactly the same: a program that purports to handle arbitrary Unicode
> text should be able to handle arbitrary Unicode text, not "Unicode
> text as long as it contains only codepoints within the range X-Y". It
> doesn't matter whether the code chokes on U+, U+005C, U+FFFC, or
> U+1F4A3 - if your code blows up, it's a failure in your code.
> 
> > Lets please stick to UTF-16 shall we?
> >
> > Now tell me:
> > - Is it broken or not?
> > - Is it widely used or not?
> > - Should programmers be careful of it or not?
> > - Should programmers be warned about it or not?
> 
> No, UTF-16 is not itself broken. (It would be if we expected
> codepoints >0x10, and it's because of UTF-16 that that's the cap
> on Unicode, but it's looking unlikely that we'll be needing any more
> than that anyway.) What's broken is code that tries to treat UTF-16 as
> if it's UCS-2, and then breaks on surrogate pairs.
> 
> Yes, it's widely used. Programmers should probably be warned about it,
> but only because its tradeoffs are generally poorer than UTF-8's. If
> you use it correctly, there's no problem.
> 
> > Also:
> > Can a programmer who is away from UTF-16 in one part of the system (say by 
> > using python3)
> > assume he is safe all over?
> 
> I don't know what you mean here. Do you mean that your Python 3
> program is "at risk" in some way because there might be some other
> program that misuses UTF-16?

Yes some other program/library/API etc connected to the python one

> Well, sure. And there might be some other
> program that misuses buffer sizes, SQL queries, or shell invocations,
> and makes your overall system vulnerable to buffer overruns or
> injection attacks. These are significantly more likely AND more
> serious than UTF-16 misuses. And you still have not proven anything
> about SMP characters being a problem, but only that code can be
> broken. Broken code is still broken code, no matter what your actual
> brokenness.

Roy Smith (and many other links Ive cited) prove exactly that - an
SMP character broke the code.

Note: I have no objection to people supporting full unicode 7.
Im just saying it may be significantly harder than just "Use python3 and you 
are done"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is nan in (nan,) correct?

[Rustom Mody]

On Friday, March 6, 2015 at 3:31:58 PM UTC+5:30, Chris Angelico wrote:
> On Fri, Mar 6, 2015 at 8:50 PM, Rustom Mody  wrote:
> > In a language like python with decent exceptions we do not need nans.
> 
> Not so. I could perhaps accept that we don't need signalling NaNs, as
> they can be replaced with exceptions, but quiet NaNs are by definition
> _not_ exceptions.

My impression (maybe I am wrong):
"Catch an exception and ignore it" is a way of converting signalling to quiet
With the added advantage of being able to tweak the specs of what happens when
nan op normal to one's taste
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Speeding up permutations generation

[Gene Heskett]

On Friday 06 March 2015 03:24:48 Abhiram R wrote:
> > A list of 100 elements has approximately 9.33 x 10**157
> > permutations. If you could somehow generate one permutation every
> > yoctosecond, exhausting them would still take more than a hundred
> > orders of magnitude longer than the age of the universe.
> > --
> > https://mail.python.org/mailman/listinfo/python-list
>
> ​True that :D I may have exaggerated on the number. Let's consider
> something more practically manageable​ => 50 elements with a 50!
> permutation.
> Is there a solution now?

Yes, but its now only 8.881784197e+84 elements so it is still not a 
practical target.  Doing all elements of a matrix is generally equ to 
n!, and 50 raised to the 50th power is still a number that will probably 
use up this suns remaining lifetime doing it in assembly.  If submitted 
and accepted to BOINC with its parallelism potential.  And 
Seagate/Western Digital's combined output for about that same time to 
store the result.

I'd choose any other, perhaps less exhaustive method.  Or a more 
practical size of dataset parameters.

> ​-Abhiram.R
> *~Never give up*

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Speeding up permutations generation

[Mark Lawrence]

On 06/03/2015 09:59, Chris Angelico wrote:

On Fri, Mar 6, 2015 at 7:24 PM, Abhiram R  wrote:

A list of 100 elements has approximately 9.33 x 10**157 permutations.
If you could somehow generate one permutation every yoctosecond,
exhausting them would still take more than a hundred orders of
magnitude longer than the age of the universe.
--
https://mail.python.org/mailman/listinfo/python-list



True that :D I may have exaggerated on the number. Let's consider something
more practically manageable => 50 elements with a 50! permutation.
Is there a solution now?



Is the actual generation of permutations your problem? You mentioned
that you're using itertools, so I would expect that you're simply
iterating over that; I hope you're not immediately trying to construct
a list of them all, because that would cost the memory that Mark's
response talks about. Have you actually profiled your code and found
that generating permutations is the bottleneck, or did you just guess?
Because even experienced programmers - even extremely experienced
Python programmers - are usually wrong when they guess about the
slowest part of a program. The only way to know is to measure.

ChrisA



s/Mark/Wolfgang/ ?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Speeding up permutations generation

[Dave Angel]

On 03/06/2015 05:32 AM, Gene Heskett wrote:



On Friday 06 March 2015 03:24:48 Abhiram R wrote:

A list of 100 elements has approximately 9.33 x 10**157
permutations. If you could somehow generate one permutation every
yoctosecond, exhausting them would still take more than a hundred
orders of magnitude longer than the age of the universe.
--
https://mail.python.org/mailman/listinfo/python-list


​True that :D I may have exaggerated on the number. Let's consider
something more practically manageable​ => 50 elements with a 50!
permutation.
Is there a solution now?


Yes, but its now only 8.881784197e+84 elements so it is still not a
practical target.  Doing all elements of a matrix is generally equ to
n!, and 50 raised to the 50th power is still a number that will probably
use up this suns remaining lifetime doing it in assembly.



Sorry, but 50! is not even close to 50**50.  The latter is 85 digits as 
you say, but 50! is "only" 64.



30414093201713378043612608166064768844377641568960512L


Still an enormous number of course, so an exhaustive visit to all those 
permutations is still impossible on a conventional computer.


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

Re: Speeding up permutations generation

[Dave Angel]

On 03/06/2015 01:44 AM, Abhiram R wrote:

Hi all,
Is there a way to generate permutations of large arrays of sizes say,in the
hundreds, faster than in the time itertools.permutations() can return?



When dealing with large loops like that (or even permutations of 50, 
which is also gy-normous [1]), you have to consider what work you plan 
to do in the loop.


Even if the generation were instantaneous, you still presumably are 
going to have some code in the loop.


If you expect to do it on a set of 50, you're going to have to narrow 
down the possibilities with some approach other than brute force.


What's the problem you were hoping to solve in the next trillion years?


[1]  50! = 
30414093201713378043612608166064768844377641568960512L



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

Re: HELP!! How to ask a girl out with a simple witty Python code??

[alister]

On Fri, 06 Mar 2015 14:23:22 +1100, Ben Finney wrote:

> 
> No. I'm saying that it's clear the person saying “get their panties all
> up in a bunch” fully intends to convey specifically *female* underwear,
> and thereby to use implied femininity as an insult.
> 
> Yes, of course I know some people who aren't female wear panties. Yes,
> of course I know some women wear underwear that isn't panties. Don't try
> to change the topic with absurd logical extremes that I didn't raise.
> 
> I'm talking about the implication of the comment as a gendered insult.
> 
>> It's only gender specific if you accept the sexist gendered stereotype
>> that all women are by definition thin-skinned and excessively
>> sensitive.
> 
> Bullshit. I said nothing about the sensitivity of anyone. Individual
> women you may know – even *all* women, everywhere – could be as tough as
> nails, and it doesn't address the point I'm raising.
> 
> Whether any particular woman is targeted or not, the comment I'm
> responding to invokes female gender as an implied insult. That's
> unwelcoming to women, and I don't want such unwelcoming attitudes in
> this community.

I have not seen one female poster on this site claim to be offended by 
the comment or even consider it to be a slur.

I doubt that the original poster of the comment intended it to be either 
& most people reading it would have known that (regardless of their 
gender)

one thing i personally find offensive is when someone raises an issue on 
someone else's behalf because they THINK they MIGHT get offended without 
bothering to check.

I am not female so this particular instance does not relate to me but an 
example from a few years ago was when a popular UK soap made an extreme 
effort not to show a cross or Christmas tree during a church wedding in 
case it "offended not-Christians".

I am a non-Christian & found that decision offensive.




-- 
Never trust an operating system you don't have sources for.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Speeding up permutations generation

[Chris Angelico]

On Fri, Mar 6, 2015 at 9:33 PM, Mark Lawrence  wrote:
>> Is the actual generation of permutations your problem? You mentioned
>> that you're using itertools, so I would expect that you're simply
>> iterating over that; I hope you're not immediately trying to construct
>> a list of them all, because that would cost the memory that Mark's
>> response talks about. Have you actually profiled your code and found
>> that generating permutations is the bottleneck, or did you just guess?
>> Because even experienced programmers - even extremely experienced
>> Python programmers - are usually wrong when they guess about the
>> slowest part of a program. The only way to know is to measure.
>>
>> ChrisA
>>
>
> s/Mark/Wolfgang/ ?

Oops, yes, my bad. I read the rest of the thread, then went back up
and replied to the most appropriate post for what I wanted to say, and
then named the wrong person out of the two following posters. My
apologies, Mark and Wolfgang!

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

Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]

[Steve Hayes]

On Fri, 6 Mar 2015 00:00:28 -0800 (PST), Rustom Mody
 wrote:

>On Thursday, March 5, 2015 at 10:49:54 AM UTC+5:30, Marko Rauhamaa wrote:
>> Rustom Mody:
>> 
>> > You keep talking of accent.
>> > At first I thought you were using the word figuratively or else joking.
>> > Im now beginning to wonder if you mean it literally.
>> > If so have you patented a new AOIP protocol?
>> > If not do you give tuitions¹ in ESP/telepathy/Voodoo? I'll be happy to
>> > pay
>> 
>> Where I work, people do use voice still occasionally to communicate.
>
>I really dont understand what we are communicating (or not) about...
>
>Can you hear my accent? I certainly cant hear yours

And if I call a Python list "books", is Python going to complain about
my accent? Really?


-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]

[alister]

On Fri, 06 Mar 2015 08:31:40 +, Mark Lawrence wrote:

> On 06/03/2015 08:00, Rustom Mody wrote:
>> On Thursday, March 5, 2015 at 10:49:54 AM UTC+5:30, Marko Rauhamaa
>> wrote:
>>> Rustom Mody:
>>>
 You keep talking of accent.
 At first I thought you were using the word figuratively or else
 joking.
 Im now beginning to wonder if you mean it literally.
 If so have you patented a new AOIP protocol?
 If not do you give tuitions¹ in ESP/telepathy/Voodoo? I'll be happy
 to pay
>>>
>>> Where I work, people do use voice still occasionally to communicate.
>>
>> I really dont understand what we are communicating (or not) about...
>>
>> Can you hear my accent? I certainly cant hear yours If you are talking
>> of accent (aural/physical just to be clear) of your co-workers how is
>> that more on-topic or relevant to this list than the weather in
>> Finland.
>> [Yeah its been freakish weather out here for the last 10 days -- global
>> warming?
>> And is global warming on topic for this list?]
>> Just to be clear -- I am going to be one of the tail-enders complaining
>> about on/off-topicness.  But someone or other will complain I guess.
>>
>> If on the other hand you are being slightly metaphorical and using
>> 'accent'
>> to talk of (say) Mark's britishisms¹ then please disambiguate for
>> better communication.
>>
>> But more to the point its still not clear (to me) whether you are
>> objecting to - to Mark - to British accent
> 
> British accent, Christmas is early this year so ho, ho, ho.  Nobody in
> this country ever guesses where I was born and bred, they all think I'm
> from the South West or the West Country.  Irish, Scottish, Welsh,
> English alone are different.  Most foreigners wouldn't have a dog's
> chance in hell of understanding a Geordie or a Glaswegian.  Move 50
> miles and you can hear a completely different accent.  British accent
> indeed.
> 
Foreigner? I can barely understand a Geordie accent & I am English.
whilst I agree to a point with Marco that when talking to a forigner you 
should take care to speak clearly for them the suggestion that American 
pronunciation is what I find unacceptable.

even though I can (and do) watch American TV shows reasonably easily some 
of their pronunciations seriously grate on my nerves :-

Bouy - it is pounced Boy not bo-ey!
chasis - it has a soft Ch  not a hard Ch,
Aluminium, Heck they don't even sell it correctly ;-)


>> - to British spellings in software - to anyone/anywhere international,
>> using non-international format
>>
>>
>> ¹Personally I find Mark's britishisms sometimes funny eg I found this
>>   https://groups.google.com/d/msg/comp.lang.python/EfloMHB3DjQ/
ZdY3Vn_6rpsJ
>>   hilarious even though I could not decipher more than 70% of the
>>   british accent.
>> Sometimes though I find it irrelevant/unnecessary/undecipherable.
>>
>> Personally I am not going to object to him nor am I going to object to
>> anyone objecting to him.
>>
>>
> Anybody objecting about me will be accused by me of discrimination
> against autistic people.  Now there is a not very subtle hint that might
> penetrate one or two of the thicker skins on the thicker heads that
> participate here.  Thankfully the numbers of such people are extremely
> small or we could have had WWIII.  Which could have happened when Global
> Crossing bought Racal Telecommunications and tried to stop us Brits
> using our kettles to make our cuppas.  Now that is seriously brain dead.
>   And they turned out to be a bit naughty with the books :(





-- 
"All my life I wanted to be someone; I guess I should have been more 
specific."
-- Jane Wagner
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie question about text encoding

[random832]

On Fri, Mar 6, 2015, at 04:06, Rustom Mody wrote:
> Also:
> Can a programmer who is away from UTF-16 in one part of the system (say
> by using python3)
> assume he is safe all over?

The most common failure of UTF-16 support, supposedly, is in programs
misusing the number of code units (for length or random access) as a
proxy for the number of characters.

However, when do you _really_ want the number of characters? You may
want to use it for, for example, the number of columns in a 'monospace'
font, which you've already screwed up because you haven't accounted for
double-wide characters or combining marks. Or you may want the position
that pressing an arrow key or backspace or forward-delete a number of
times will reach, which has its own rules in e.g. Indic languages (and
also fails on Latin with combining marks).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie question about text encoding

[Chris Angelico]

On Sat, Mar 7, 2015 at 12:33 AM,   wrote:
> However, when do you _really_ want the number of characters? You may
> want to use it for, for example, the number of columns in a 'monospace'
> font, which you've already screwed up because you haven't accounted for
> double-wide characters or combining marks. Or you may want the position
> that pressing an arrow key or backspace or forward-delete a number of
> times will reach, which has its own rules in e.g. Indic languages (and
> also fails on Latin with combining marks).

Number of code points is the most logical way to length-limit
something. If you want to allow users to set their display names but
not to make arbitrarily long ones, limiting them to X code points is
the safest way (and preferably do an NFC or NFD normalization before
counting, for consistency); this means you disallow pathological cases
where every base character has innumerable combining marks added.

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

Re: io.open vs. codecs.open

[Albert-Jan Roskam]

- Original Message -

> From: Steven D'Aprano 
> To: python-list@python.org
> Cc: 
> Sent: Wednesday, March 4, 2015 8:56 PM
> Subject: Re: io.open vs. codecs.open
> 
> Albert-Jan Roskam wrote:
> 
>>  Hi,
>> 
>>  Is there a (use case) difference between codecs.open and io.open? What is
>>  the difference? A small difference that I just discovered is that
>>  codecs.open(somefile).read() returns a bytestring if no encoding is
>>  specified*), but a unicode string if an encoding is specified. io.open
>>  always returns a unicode string.
> 
> What version of Python are you using?


Python 2.7 and 3.4.


> In Python 3, io.open is used as the built-in open. I believe this is
> guaranteed, and not just an implementation detail.
> 
> The signatures and capabilities are quite different:
> 
> codecs.open:
> 
> open(filename, mode='rb', encoding=None, errors='strict', 
> buffering=1)
> 
> io.open:
> 
> open(file, mode='r', buffering=-1, encoding=None,

>  errors=None, newline=None, closefd=True, opener=None)

Thanks. I didn't realize that closefd was also available in Python 2. I had 
only seen it in Python 3 open()

> 
> io.open does *not* always produce Unicode strings. If you pass 'rb' as 
> the
> mode, the file is opened in binary mode, not text mode, and the read()
> method will return bytes.



So, in recent versions of Python 2 (Python 2.7.x, 2.6) I can basically ditch 
codecs.open() and the standard open()?
Given that standard open() has no encoding parameter, it is only really safe 
for use with binary data (binary mode).


> As usual, help() in the interactive interpreter is your friend.
> help(codecs.open) and help(io.open) will explain the many differences
> between them, including that codecs.open always opens the file in binary
> mode.
> 
> As for use-cases, I think that codecs.open is mostly a left-over from the
> Python 2 days when the built-in open had a much simpler interface and fewer
> capabilities. In Python 2, built-in open doesn't take an encoding argument,
> so if you want to use something other than binary mode or the default
> encoding, you were supposed to use codecs.open.
> 
> In Python 2.6, the io module was added to Python 2 to aid in porting to
> Python 3. The docs say:
> 
> New in version 2.6.
> 
> The io module provides the Python interfaces to stream handling.
> Under Python 2.x, this is proposed as an alternative to the
> built-in file object, but in Python 3.x it is the default
> interface to access files and streams.
> 
> https://docs.python.org/2/library/io.html
> 
> 
> To summarise:
> 
> * In Python 2, if you want to supply an encoding to open, use codecs.open
> (before 2.6) or io.open (2.6 and later);
> 
> * If you want the enhanced capabilities of Python 3 open, use io.open;
> 
> * In Python 3, io.open is the same thing as built-in open;
> 
> * And codecs.open is (I think) mostly there for backwards compatibility.
> 
> 
> 
> 
> -- 
> Steven
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie question about text encoding

[random832]

On Fri, Mar 6, 2015, at 08:39, Chris Angelico wrote:
> Number of code points is the most logical way to length-limit
> something. If you want to allow users to set their display names but
> not to make arbitrarily long ones, limiting them to X code points is
> the safest way (and preferably do an NFC or NFD normalization before
> counting, for consistency);

Why are you length-limiting it? Storage space? Limit it in whatever
encoding they're stored in. Why are combining marks "pathological" but
surrogate characters not? Display space? Limit it by columns. If you're
going to allow a Japanese user's name to be twice as wide, you've got a
problem when you go to display it.

> this means you disallow pathological cases
> where every base character has innumerable combining marks added.

No it doesn't. If you limit it to, say, fifty, someone can still post
two base characters with twenty combining marks each. If you actually
want to disallow this, you've got to do more work. You've disallowed
some of the pathological cases, some of the time, by coincidence. And
limiting the number of UTF-8 bytes, or the number of UTF-16 code points,
will accomplish this just as well.

Now, if you intend to _silently truncate_ it to the desired length, you
certainly don't want to leave half a character in, of course. But who's
to say the base character plus first few combining marks aren't also
"half a character"? If you're _splitting_ a string, rather than merely
truncating it, you probably don't want those combining marks at the
beginning of part two.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie question about text encoding

[Chris Angelico]

On Sat, Mar 7, 2015 at 1:03 AM,   wrote:
> On Fri, Mar 6, 2015, at 08:39, Chris Angelico wrote:
>> Number of code points is the most logical way to length-limit
>> something. If you want to allow users to set their display names but
>> not to make arbitrarily long ones, limiting them to X code points is
>> the safest way (and preferably do an NFC or NFD normalization before
>> counting, for consistency);
>
> Why are you length-limiting it? Storage space? Limit it in whatever
> encoding they're stored in. Why are combining marks "pathological" but
> surrogate characters not? Display space? Limit it by columns. If you're
> going to allow a Japanese user's name to be twice as wide, you've got a
> problem when you go to display it.

To prevent people from putting three paragraphs of lipsum in and
calling it a username.

>> this means you disallow pathological cases
>> where every base character has innumerable combining marks added.
>
> No it doesn't. If you limit it to, say, fifty, someone can still post
> two base characters with twenty combining marks each. If you actually
> want to disallow this, you've got to do more work. You've disallowed
> some of the pathological cases, some of the time, by coincidence. And
> limiting the number of UTF-8 bytes, or the number of UTF-16 code points,
> will accomplish this just as well.

They can, but then they're limited to two base characters. They can't
have fifty base characters with twenty combining marks each. That's
the point.

> Now, if you intend to _silently truncate_ it to the desired length, you
> certainly don't want to leave half a character in, of course. But who's
> to say the base character plus first few combining marks aren't also
> "half a character"? If you're _splitting_ a string, rather than merely
> truncating it, you probably don't want those combining marks at the
> beginning of part two.

So you truncate to the desired length, then if the first character of
the trimmed-off section is a combining mark (based on its Unicode
character types), you keep trimming until you've removed a character
which isn't. Then, if you no longer have any content whatsoever,
reject the name. Simple.

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

Re: Newbie question about text encoding

[random832]

On Fri, Mar 6, 2015, at 09:11, Chris Angelico wrote:
> To prevent people from putting three paragraphs of lipsum in and
> calling it a username.

Limiting by UTF-8 bytes or UTF-16 units works just as well for that.

> So you truncate to the desired length, then if the first character of
> the trimmed-off section is a combining mark (based on its Unicode
> character types), you keep trimming until you've removed a character
> which isn't. Then, if you no longer have any content whatsoever,
> reject the name. Simple.

My entire point was that UTF-32 doesn't save you from that, so it cannot
be called a deficiency of UTF-16. My point is there are very few
problems to which "count of Unicode code points" is the only right
answer - that UTF-32 is good enough for but that are meaningfully
impacted by a naive usage of UTF-16, to the point where UTF-16 is
something you have to be "safe" from.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie question about text encoding

[Steven D'Aprano]

Rustom Mody wrote:

> On Friday, March 6, 2015 at 10:50:35 AM UTC+5:30, Chris Angelico wrote:

[snip example of an analogous situation with NULs]

> Strawman.

Sigh. If I had a dollar for every time somebody cried "Strawman!" when what
they really should say is "Yes, that's a good argument, I'm afraid I can't
argue against it, at least not without considerable thought", I'd be a
wealthy man...


> Lets please stick to UTF-16 shall we?
> 
> Now tell me:
> - Is it broken or not?

The UTF-16 standard is not broken. It is a perfectly adequate variable-width
encoding, and considerably better than most other variable-width encodings.

However, many implementations of UTF-16 are faulty, and assume a
fixed-width. *That* is broken, not UTF-16.

(The difference between specification and implementation is critical.)


> - Is it widely used or not?

It's quite widely used.


> - Should programmers be careful of it or not?

Programmers should be aware whether or not any specific language uses UTF-16
and whether the implementation is buggy. That will help them decide whether
or not to use that language.


> - Should programmers be warned about it or not?

I'm in favour of people having more knowledge rather than less. I don't
believe that ignorance is bliss, except perhaps in the case that a giant
asteroid the size of Texas is heading straight for us.

Programmers should be aware of the limitations or bugs in any UTF-16
implementation they are likely to run into. Hence my general
recommendation:

- For transmission over networks or storage on permanent media (e.g. the
content of text files), use UTF-8. It is well-implemented by nearly all
languages that support Unicode, as far as I know.

- If you are designing your own language, your implementation of Unicode
strings should use something like Python's FSR, or UTF-8 with tweaks to
make string indexing O(1) rather than O(N), or correctly-implemented
UTF-16, or even UTF-32 if you have the memory. (Choices, choices.) If, in
2015, you design your Unicode implementation as if UTF-16 is a fixed 2-byte
per code point format, you fail.

- If you are using an existing language, be aware of any bugs and
limitations in its Unicode implementation. You may or may not be able to
work around them, but at least you can decide whether or not you wish to
try.

- If you are writing your own file system layer, it's 2015 fer fecks sake,
file names should be Unicode strings, not bytes! (That's one part of the
Unix model that needs to die.) You can use UTF-8 or UTF-16 in the file
system, whichever you please, but again remember that both are
variable-width formats.



-- 
Steven

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

Re: Newbie question about text encoding

[Chris Angelico]

On Sat, Mar 7, 2015 at 1:50 AM, Steven D'Aprano
 wrote:
> Rustom Mody wrote:
>
>> On Friday, March 6, 2015 at 10:50:35 AM UTC+5:30, Chris Angelico wrote:
>
> [snip example of an analogous situation with NULs]
>
>> Strawman.
>
> Sigh. If I had a dollar for every time somebody cried "Strawman!" when what
> they really should say is "Yes, that's a good argument, I'm afraid I can't
> argue against it, at least not without considerable thought", I'd be a
> wealthy man...

If I had a dollar for every time anyone said "If I had  for every time...", I'd go meta all day long and
profit from it... :)

> - If you are writing your own file system layer, it's 2015 fer fecks sake,
> file names should be Unicode strings, not bytes! (That's one part of the
> Unix model that needs to die.) You can use UTF-8 or UTF-16 in the file
> system, whichever you please, but again remember that both are
> variable-width formats.

I agree that that part of the Unix model needs to change, but there
are two viable ways to move forward:

1) Keep file names as bytes, but mandate that they be valid UTF-8
streams, and recommend that they be decoded UTF-8 for display to a
human
2) Change the entire protocol stack from the file system upwards so
that file names become Unicode strings.

Trouble with #2 is that file names need to be passed around somehow,
which means bytes in memory. So ultimately, #2 really means "keep file
names as bytes, and mandate an encoding all the way up the stack"...
so it's a massive documentation change that really comes down to the
same thing as #1.

This is one area where, as I understand it, Mac OS got it right. It's
time for other Unix variants to adopt the same policy. The bulk of
file names will be ASCII-only anyway, so requiring UTF-8 won't affect
them; a lot of others are already UTF-8; so all we need is a
transition scheme for the remaining ones. If there's a known FS
encoding, it ought to be possible to have a file system conversion
tool that goes through everything, decodes, re-encodes UTF-8, and then
flags the file system as UTF-8 compliant. All that'd be left would be
the file names that are broken already - ones that don't decode in the
FS encoding - and there's nothing to be done with them but wrap them
up into something probably-meaningless-but reversible.

When can we start doing this? ext5?

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

Re: Is nan in (nan,) correct?

[Grant Edwards]

On 2015-03-06, Chris Angelico  wrote:
> On Fri, Mar 6, 2015 at 8:50 PM, Rustom Mody  wrote:
>> In a language like python with decent exceptions we do not need nans.
>
> Not so. I could perhaps accept that we don't need signalling NaNs, as
> they can be replaced with exceptions, but quiet NaNs are by definition
> _not_ exceptions.

And quiet NaNs are very, very useful.

-- 
Grant Edwards   grant.b.edwardsYow! A can of ASPARAGUS,
  at   73 pigeons, some LIVE ammo,
  gmail.comand a FROZEN DAQUIRI!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Speeding up permutations generation

[Gene Heskett]

On Friday 06 March 2015 06:22:34 Dave Angel wrote:
> On 03/06/2015 05:32 AM, Gene Heskett wrote:
> > On Friday 06 March 2015 03:24:48 Abhiram R wrote:
> >>> A list of 100 elements has approximately 9.33 x 10**157
> >>> permutations. If you could somehow generate one permutation every
> >>> yoctosecond, exhausting them would still take more than a hundred
> >>> orders of magnitude longer than the age of the universe.
> >>> --
> >>> https://mail.python.org/mailman/listinfo/python-list
> >>
> >> ​True that :D I may have exaggerated on the number. Let's consider
> >> something more practically manageable​ => 50 elements with a 50!
> >> permutation.
> >> Is there a solution now?
> >
> > Yes, but its now only 8.881784197e+84 elements so it is still not a
> > practical target.  Doing all elements of a matrix is generally equ
> > to n!, and 50 raised to the 50th power is still a number that will
> > probably use up this suns remaining lifetime doing it in assembly.
>
> Sorry, but 50! is not even close to 50**50.  The latter is 85 digits
> as you say, but 50! is "only" 64.
>
>
> 30414093201713378043612608166064768844377641568960512L

What utility output that as an L ?

But you are right, new wheezy install with TBE desktop and kcalc has been 
played with. I used the wrong button.  It seems every new and 
streamlined version is progressively stripped of some function I have 
formerly found useful,  Grr. Not related to this, but now the binary 
bit display has been excised.  Handier than bottled beer when 
checking/designing address decoders.

> Still an enormous number of course, so an exhaustive visit to all
> those permutations is still impossible on a conventional computer.
+5
>
> --
> DaveA

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: HELP!! How to ask a girl out with a simple witty Python code??

[Ian Kelly]

On Fri, Mar 6, 2015 at 4:53 AM, alister
 wrote:
> I have not seen one female poster on this site claim to be offended by
> the comment or even consider it to be a slur.
>
> I doubt that the original poster of the comment intended it to be either
> & most people reading it would have known that (regardless of their
> gender)
>
> one thing i personally find offensive is when someone raises an issue on
> someone else's behalf because they THINK they MIGHT get offended without
> bothering to check.

"Offended" is a rather vacuous term. It describes a distraught
emotional state without any attempt to reason about what actual
problem might exist. Too often somebody simply says "I'm offended by
X" and then a lot of people kowtow to that statement as if it in
itself were a reason to check behavior.

But that doesn't make it unimportant to measure the kinds of messages
that our actions send, and that's not what's going on here. Ben has
clearly laid out how the comment creates an unwelcoming environment to
women and so marginalizes them. That's a problem even if no women are
speaking up about the comment, because a) there may be some who find
the comment troubling but are unwilling to speak up about it
("suffering in silence"), and b) it doesn't even matter if somebody
says that they don't mind being insulted; it still creates a problem
and it's still not socially acceptable to insult them.


> I am not female so this particular instance does not relate to me but an
> example from a few years ago was when a popular UK soap made an extreme
> effort not to show a cross or Christmas tree during a church wedding in
> case it "offended not-Christians".
>
> I am a non-Christian & found that decision offensive.

I agree that example sounds idiotic. Where is the problem with
depicting Christian paraphernalia in a clearly Christian setting?
There is a great difference between showing Christian imagery and
showing a world that is exclusionary of or hostile to non-Christians.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]

[llanitedave]

On Friday, March 6, 2015 at 2:03:42 AM UTC-8, Marko Rauhamaa wrote:
> Rustom Mody :
> 
> > I really dont understand what we are communicating (or not) about...
> >
> > Can you hear my accent?
> 
> If we met at a Python conference, I would hear it and hopefully even
> understand it.
> 
> > But more to the point its still not clear (to me) whether you are objecting 
> > to
> > - to Mark
> > - to British accent
> > - to British spellings in software
> > - to anyone/anywhere international, using non-international format
> 
> I'm objecting (mildly) to British spellings in source code and technical
> documentation.
> 
> I'm objecting (more strongly) to local English accents in settings
> including but not limited to:
> 
>  - conference speeches with international audiences
> 
>  - group discussions with international participants
> 
>  - teleconferences with international participants
> 
> In my experience, it is harder to understand most British English
> accents than, say, a run-of-the-mill Chinese engineer trying to speak
> English. It has to do with pronunciation, speed and eloquence (too much
> of it with native speakers).
> 
> 
> Marko

It's obvious that's what's needed here is a PEP requiring that the 
International Phonetic Alphabet be used for all Python identifiers and keywords.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: HELP!! How to ask a girl out with a simple witty Python code??

[llanitedave]

On Wednesday, March 4, 2015 at 6:50:32 PM UTC-8, sohca...@gmail.com wrote:
> On Wednesday, March 4, 2015 at 5:34:16 PM UTC-8, Xrrific wrote:
> > Guys, please Help!!!
> > 
> > I am trying to impress a girl who is learning python and want ask her out 
> > at the same time.
> > 
> > Could you please come up with something witty incorporating a simple python 
> > line like If...then... but..etc.
> > 
> > You will make me a very happy man!!!
> > 
> > Thank you very much!!!
> 
> You're asking a bunch of nerds for dating advice?

Girls can be nerds too, ya know...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Speeding up permutations generation

[Dave Angel]

On 03/06/2015 11:14 AM, Gene Heskett wrote:



On Friday 06 March 2015 06:22:34 Dave Angel wrote:




Sorry, but 50! is not even close to 50**50.  The latter is 85 digits
as you say, but 50! is "only" 64.


30414093201713378043612608166064768844377641568960512L


What utility output that as an L ?



Python 2.7 interpreter, after calculating factorial with the obvious 
loop.  Basically, it's using repr() on the expression, so it flags the 
integer as a long, rather than an int.


I debated not including it, but this way I was sure of getting the right 
number of zeroes.  My copy/paste is notorious for missing a character or 
two at each end.


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

Re: HELP!! How to ask a girl out with a simple witty Python code??

[Mark Lawrence]

On 06/03/2015 11:53, alister wrote:

On Fri, 06 Mar 2015 14:23:22 +1100, Ben Finney wrote:



No. I'm saying that it's clear the person saying “get their panties all
up in a bunch” fully intends to convey specifically *female* underwear,
and thereby to use implied femininity as an insult.

Yes, of course I know some people who aren't female wear panties. Yes,
of course I know some women wear underwear that isn't panties. Don't try
to change the topic with absurd logical extremes that I didn't raise.

I'm talking about the implication of the comment as a gendered insult.


It's only gender specific if you accept the sexist gendered stereotype
that all women are by definition thin-skinned and excessively
sensitive.


Bullshit. I said nothing about the sensitivity of anyone. Individual
women you may know – even *all* women, everywhere – could be as tough as
nails, and it doesn't address the point I'm raising.

Whether any particular woman is targeted or not, the comment I'm
responding to invokes female gender as an implied insult. That's
unwelcoming to women, and I don't want such unwelcoming attitudes in
this community.


I have not seen one female poster on this site claim to be offended by
the comment or even consider it to be a slur.

I doubt that the original poster of the comment intended it to be either
& most people reading it would have known that (regardless of their
gender)

one thing i personally find offensive is when someone raises an issue on
someone else's behalf because they THINK they MIGHT get offended without
bothering to check.

I am not female so this particular instance does not relate to me but an
example from a few years ago was when a popular UK soap made an extreme
effort not to show a cross or Christmas tree during a church wedding in
case it "offended not-Christians".

I am a non-Christian & found that decision offensive.



When a UK TV station showed the Dam Busters film some years ago and 
edited out the part about the burial of Guy Gibson's dog, I wasn't 
offended, I was downright livid.  How dare they distort history in an 
attempt to avoid offending people.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Speeding up permutations generation

[Wolfgang Maier]

On 03/06/2015 05:14 PM, Gene Heskett wrote:



On Friday 06 March 2015 06:22:34 Dave Angel wrote:


30414093201713378043612608166064768844377641568960512L


What utility output that as an L ?



One called the python interactive interpreter used by many people on 
this list (though it is a shame they haven't switched to python3 yet) :)


Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> from math import factorial
>>> factorial(50)

30414093201713378043612608166064768844377641568960512L

Wolfgang


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

Re: Newbie question about text encoding

[Chris Angelico]

On Sat, Mar 7, 2015 at 3:20 AM, Rustom Mody  wrote:
> C's string is not bug-prone its plain buggy as it cannot represent strings
> with nulls.
>
> I would not go that far for UTF-16.
> It is bug-inviting but it can also be implemented correctly

C's standard library string handling functions are restricted in that
they handle a 255-byte alphabet. They do not handle Unicode, they do
not handle NUL, that is simply how they are. But I never said I was
talking about the C standard library. If you type a text string into a
GUI entry field, or encode it quoted-printable and pass it to a web
server, or whatever, you shouldn't know or care about what language
the program is written in; and if that program barfs on a NUL, that's
a limitation. That limitation might be caused by its naive use of
strcpy() when it should have used memcpy(), but that's not your
problem.

It's exactly the same here: if your program chokes on an SMP
character, I don't care what your program was written in or what
library functions your program called on. All I care is that your
program - repeated for emphasis, *your* program - failed on that
input. It's up to you to choose your underlying functions
appropriately.

>> - If you are designing your own language, your implementation of Unicode
>> strings should use something like Python's FSR, or UTF-8 with tweaks to
>> make string indexing O(1) rather than O(N), or correctly-implemented
>> UTF-16, or even UTF-32 if you have the memory. (Choices, choices.)
>
> FSR is possible in python for very specific pythonic reasons
> - dynamicness
> - immutable strings
>
> Drop either and FSR is impossible

I don't know what you mean by "dynamicness". What you do need is a
Unicode string type, such that the application program isn't aware of
the underlying bytes, but simply treats this string as a sequence of
code points. The immutability isn't technically a requirement, but it
does make the FSR much more manageable; in a language with mutable
strings, it's probably more efficient to use UTF-32 for simplicity,
but it's up to the language designer to figure that out. (It might be
best to use something like the FSR, but where strings are never
narrowed after being widened, so it'd be possible for an ASCII-only
string to be stored UTF-32. That has consequences for comparisons, but
might give a reasonable hybrid of storage and mutation performance.)

> _tkinter.TclError: character U+1f4a9 is above the range (U+-U+) 
> allowed by Tcl
>
> So who/what is broken?

The exception is pretty clear on that point. Tcl can't handle SMP
characters. So it's Tcl that's broken. Unless there's evidence to the
contrary, that's what I would expect to be the case.

> Correct.
> Windows is broken for using UTF-16
> Linux is broken for conflating UTF-8 and byte string.
>
> Lot of breakage out here dont you think?
> May be related to the equation
>
> UTF-16 = UCS-2 + Duct-tape

UTF-16 is an encoding that was designed to be backward-compatible with
UCS-2, just as UTF-8 was designed to be compatible with ASCII. Call it
what you will, but backward compatibility is pretty important. Look at
things like DES3 - if you use the same key three times, it's
compatible with DES.

Linux isn't "broken" for conflating UTF-8 and byte strings. Linux is
flawed in that it defines file names to be byte strings, which means
that every file system could be different in what it actually uses as
the encoding. Since file names exist for the benefit of humans, they
should be treated as text, so we should work with them as text. But
for reasons of backward compatibility, Linux hasn't yet changed.

Windows isn't broken for using UTF-16. I think it's a poor trade-off,
given that so many file names are ASCII-only; and, of course, if any
program treats a Windows file name as UCS-2, then that program is
broken. But UTF-16 is not itself broken, any more than UTF-7 is. And
UTF-7 is a lot harder to work with.

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

Re: Newbie question about text encoding

[Steven D'Aprano]

random...@fastmail.us wrote:

> My point is there are very few
> problems to which "count of Unicode code points" is the only right
> answer - that UTF-32 is good enough for but that are meaningfully
> impacted by a naive usage of UTF-16, to the point where UTF-16 is
> something you have to be "safe" from.

I'm not sure why you care about the "count of Unicode code points", although
that *is* a problem. Not for end-user reasons like "how long is my
password?", but because it makes your job as a programmer harder.


[steve@ando ~]$ python2.7 -c "print (len(u'\U:\U00014445'))"
4
[steve@ando ~]$ python3.3 -c "print (len(u'\U:\U00014445'))"
3

It's hard to reason about your code when something as fundamental as the
length of a string is implementation-dependent. (By the way, the right
answer should be 3, not 4.)


But an even more important problem is that broken-UTF-16 lets you create
invalid, impossible Unicode strings *by accident*. Naturally you can create
broken Unicode if you assemble strings of surrogates yourself, but
broken-UTF-16 means it can happen from otherwise innocuous operations like
reversing a string:

py> s = u'\U:\U00014445'  # Python 2.7 narrow build
py> s[::-1]
u'\udc45\ud811:\u'


It's hard for me to demonstrate that the reversed string is broken because
the shell I am using does an amazingly good job of handling broken Unicode.
Even if I print it, the shell just prints missing-character glyphs instead
of crashing (fortunately for me!). But the first two code points are in
illegal order:

\udc45 is a high surrogate, and must follow a low surrogate;
\ud811 is a low surrogate, and must precede a high surrogate;

I'm not convinced you should be allowed to create Unicode strings containing
mismatched surrogates like this deliberately, but you certainly shouldn't
be able to do so by accident.


-- 
Steven

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

Re: Is nan in (nan,) correct?

[Steven D'Aprano]

Rustom Mody wrote:

> On Friday, March 6, 2015 at 3:57:12 AM UTC+5:30, rand...@fastmail.us
> wrote:
>> It's been brought up on Stack Overflow that the "in" operator (on
>> tuples, and by my testing on dict and list, as well as dict lookup) uses
>> object identity as a shortcut, and returns true immediately if the
>> object being tested *is* an element of the container. However, the
>> contains operation does not specify whether object identity or equality
>> is to be used. In effect, the built-in container types use a hybrid
>> test: "a is b or a == b".
>> 
>> My question is, is this a *correct* implementation of the operator, or
>> are objects "supposed to" use a basis of equality for these tests?
> 
> nan is an illegal or bogus value.

NANs *represent* bogus values, they aren't bogus themselves.


> As usual legalizing the illegal is always fraught with increasing
> conundrums.
> 
> The most (to me) classic instance of this is denotational semantics.
> In DS one tries to give semantics to programs by mapping programs to
> math-functions across some domains
> 
> However some programs crash. What should be the semantics of such a
> program. We say its a partial function – undefined at the crash-points.
> But partial functions are not nearly as tractable (to mathematicians!) as
> total functions.
> So we invent a bogus value  ⊥ (called bottom) and totalize all functions
> by mapping to this.
> 
> Very nice…
> 
> So nice in fact that we wish to add ⊥ to our programming language
> 
> And now all hell breaks loose because the question x == ⊥ is the halting
> problem.

Oh nonsense. x == ⊥ is easily performed with the equivalent of:

type(x) == BottomType and bit_representation(x) == bit_representation(⊥)



> And people love this problem so much they keep replicating it:
> 
> - C and null (or Pascal/Lisp and Nil)
> [Hoare's billion dollar mistake
> [https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions ]
> - nul in SQL – Should two nuls compare as same or different?
>   There are good (and different!) reasons for both answers
> - Python and None
> - Floats and nans

This is a random grab-bag of unrelated "problems" that differ in their
causes and their consequences. The only thing they have in common is that
Null/Nil/Nul/None/NAN all begin with N, and are all "special" in some
sense.


> My own thoughts on this (not very well thought out, I admit)
> The letter of the IEEE standard talks of nans and their details
> The spirit of the standard is that nans capture exception-al computations
> ie nan represents an exception
> 
> In a language like python with decent exceptions we do not need nans.

Then you are missing the most important use-case for NANs.

Really, do you think that the designers of IEEE-754 actually didn't think of
this? Long before high-level languages like Python started using
exceptions, low-level languages had "traps" that did more or less the same
thing. If all you want is merely to interrupt your calculation the first
time an error occurs, then you just trap the error condition and you're
done.

But IEEE-754 supports *not* interrupting the calculation, but allowing the
error condition to propagate all the way to the end of the calculation.
Instead of peppering your calculation with dozens of checks ("Look Before
You Leap") to avoid triggering a trap, you just perform the calculation,
and then at the end inspect the result and if it is a NAN you can decide
how to handle it ("Easier To Ask Forgiveness Than Permission"). The whole
point of NANs is to avoid traps (exceptions, signals, or whatever you want
to call this interruption) from being triggered. To replace NANs with
exceptions is to miss their whole reason for existence!

And for those who do want an immediate exception, the standard supports that
too, with *signalling NANs*, which are supposed to trap on just about every
operation. A proper IEEE-754 system will allow you to decide which
operations should trap immediately and which don't, it's not a global
all-or-nothing prospect.

Alas, although many (most? all?) FPUs these days support these features,
hardly any high-level language does. You typically cannot even control
these features from C, but have to drop down to assembly. The fine control
that IEEE-754 offers is under-utilized because the language designers don't
support it.



-- 
Steven

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

Re: Newbie question about text encoding

[Rustom Mody]

On Friday, March 6, 2015 at 8:20:22 PM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:
> 
> > On Friday, March 6, 2015 at 10:50:35 AM UTC+5:30, Chris Angelico wrote:
> 
> [snip example of an analogous situation with NULs]
> 
> > Strawman.
> 
> Sigh. If I had a dollar for every time somebody cried "Strawman!" when what
> they really should say is "Yes, that's a good argument, I'm afraid I can't
> argue against it, at least not without considerable thought", I'd be a
> wealthy man...

Missed my addition? Here it is again –  grammar slightly corrected.

===
Ah well if you insist on pursuing the nul-char example...
- No, the unicode consortium (or ASCII equivalent) is not wrong in allocating 
codepoint 0

- No, the code that "can't cope with a perfectly normal character" is not wrong

- It is C that is wrong for designing a buggy string data structure that cannot
contain a valid char.
===

In fact Chris' nul-char example is so strongly supporting my argument – 
bugginess of UTF-16 –
it is perhaps too strong even for me.

To elaborate:
Take the buggy-plane analogy I gave in
http://blog.languager.org/2015/03/whimsical-unicode.html

If a plane model crashes once in 10,000 flights compared to others that crash 
once in
one million flights we can call it bug-prone though not strictly buggy – it 
does fly  
 times safely!
OTOH if a plane is guaranteed to crash we can all it a buggy plane.

C's string is not bug-prone its plain buggy as it cannot represent strings
with nulls.

I would not go that far for UTF-16.
It is bug-inviting but it can also be implemented correctly
> 
> 
> > Lets please stick to UTF-16 shall we?
> > 
> > Now tell me:
> > - Is it broken or not?
> 
> The UTF-16 standard is not broken. It is a perfectly adequate variable-width
> encoding, and considerably better than most other variable-width encodings.
> 
> However, many implementations of UTF-16 are faulty, and assume a
> fixed-width. *That* is broken, not UTF-16.
> 
> (The difference between specification and implementation is critical.)
> 
> 
> > - Is it widely used or not?
> 
> It's quite widely used.
> 
> 
> > - Should programmers be careful of it or not?
> 
> Programmers should be aware whether or not any specific language uses UTF-16
> and whether the implementation is buggy. That will help them decide whether
> or not to use that language.
> 
> 
> > - Should programmers be warned about it or not?
> 
> I'm in favour of people having more knowledge rather than less. I don't
> believe that ignorance is bliss, except perhaps in the case that a giant
> asteroid the size of Texas is heading straight for us.
> 
> Programmers should be aware of the limitations or bugs in any UTF-16
> implementation they are likely to run into. Hence my general
> recommendation:
> 
> - For transmission over networks or storage on permanent media (e.g. the
> content of text files), use UTF-8. It is well-implemented by nearly all
> languages that support Unicode, as far as I know.
> 
> - If you are designing your own language, your implementation of Unicode
> strings should use something like Python's FSR, or UTF-8 with tweaks to
> make string indexing O(1) rather than O(N), or correctly-implemented
> UTF-16, or even UTF-32 if you have the memory. (Choices, choices.)

FSR is possible in python for very specific pythonic reasons
- dynamicness
- immutable strings

Drop either and FSR is impossible

> If, in 2015, you design your Unicode implementation as if UTF-16 is a fixed 
> 2-byte per code point format, you fail.

Seems obvious enough.
So lets see...
Here's a 2-line python program -- runs well enough when run as a command.
Program:
=
pp = "💩"
print (pp)
=
Try open it in idle3 and you get (at least I get):

$ idle3 ff.py 
Traceback (most recent call last):
  File "/usr/bin/idle3", line 5, in 
main()
  File "/usr/lib/python3.4/idlelib/PyShell.py", line 1562, in main
if flist.open(filename) is None:
  File "/usr/lib/python3.4/idlelib/FileList.py", line 36, in open
edit = self.EditorWindow(self, filename, key)
  File "/usr/lib/python3.4/idlelib/PyShell.py", line 126, in __init__
EditorWindow.__init__(self, *args)
  File "/usr/lib/python3.4/idlelib/EditorWindow.py", line 294, in __init__
if io.loadfile(filename):
  File "/usr/lib/python3.4/idlelib/IOBinding.py", line 236, in loadfile
self.text.insert("1.0", chars)
  File "/usr/lib/python3.4/idlelib/Percolator.py", line 25, in insert
self.top.insert(index, chars, tags)
  File "/usr/lib/python3.4/idlelib/UndoDelegator.py", line 81, in insert
self.addcmd(InsertCommand(index, chars, tags))
  File "/usr/lib/python3.4/idlelib/UndoDelegator.py", line 116, in addcmd
cmd.do(self.delegate)
  File "/usr/lib/python3.4/idlelib/UndoDelegator.py", line 219, in do
text.insert(self.index1, self.chars, self.tags)
  File "/usr/lib/python3.4/idlelib/ColorDelegator.py", line 82, in insert
self.delegate.insert(index, chars, tags)
  File "/usr/lib/python3.4

Re: Speeding up permutations generation

[Gene Heskett]

On Friday 06 March 2015 11:30:08 Dave Angel wrote:
> On 03/06/2015 11:14 AM, Gene Heskett wrote:
> > On Friday 06 March 2015 06:22:34 Dave Angel wrote:
> >> Sorry, but 50! is not even close to 50**50.  The latter is 85
> >> digits as you say, but 50! is "only" 64.
> >>
> >>
> >> 30414093201713378043612608166064768844377641568960512L
> >
> > What utility output that as an L ?
>
> Python 2.7 interpreter, after calculating factorial with the obvious
> loop.  Basically, it's using repr() on the expression, so it flags the
> integer as a long, rather than an int.
>
> I debated not including it, but this way I was sure of getting the
> right number of zeroes.  My copy/paste is notorious for missing a
> character or two at each end.

Chuckle, so is mine Dave.  Mouse, holding breath cuz I have a finger on a 
button, is turning blue and finally exhales in desperation sort of thing 
I guess.  Particularly against the left margin of a string. I can't see 
a single reason why a drag the mouse copy has to die if the mouse 
moves .001" past the left margin. But I didn't write it so I've no 
clue why it doesn't just take the whole damned highlighted string & be 
done with it.  

> --
> DaveA

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: HELP!! How to ask a girl out with a simple witty Python code??

[Rustom Mody]

On Friday, March 6, 2015 at 9:08:07 AM UTC+5:30, Chris Angelico wrote:
> Allow me to summarize this subthread:
> 
> * sohcahtoa makes a comment implying that this list is full of nerds
> who know nothing about dating. Gender-nonspecific and most likely
> self-deprecating as much as insulting.
> * I responded with a reference to a nerdy movie ("Real Genius", and if
> you haven't seen it, go grab it - it's funny), which perhaps was not
> recognized, leading to the post in which:
> * sohcahtoa misunderstands me and thinks I was offended at his post
> (which I wasn't), and gets his hackles up, thinking the original
> nerd-dating-advice comment shouldn't have been offensive
> * Two people then go back and forth about whether or not the previous
> three posts were offensive.
> 

Nice summary of the ridiculous
Except you missed the subject of the thread
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is nan in (nan,) correct?

[Steven D'Aprano]

Rustom Mody wrote:

> On Friday, March 6, 2015 at 3:31:58 PM UTC+5:30, Chris Angelico wrote:
>> On Fri, Mar 6, 2015 at 8:50 PM, Rustom Mody  wrote:
>> > In a language like python with decent exceptions we do not need nans.
>> 
>> Not so. I could perhaps accept that we don't need signalling NaNs, as
>> they can be replaced with exceptions, but quiet NaNs are by definition
>> _not_ exceptions.
> 
> My impression (maybe I am wrong):
> "Catch an exception and ignore it" is a way of converting signalling to
> quiet With the added advantage of being able to tweak the specs of what
> happens when nan op normal to one's taste


I don't understand what you are trying to say.

Let's take a dirt-simple example:

def inverse(x):
return 1.0/x

There's an exception there, waiting to bite. If I include inverse() in some
complex calculation:

def function(x, y):
return atan2(inverse(3*x*y)+1, inverse(1 - x**2 + 3*x - 0.2)**3)

values = [function(1.5*x, y+2) for x, y in zip(xx, yy)]

and I just wish to skip over the failed calculations, I can't just "ignore"
exceptions:

# This doesn't work!
def inverse(x):
try:
return 1.0/x
except ZeroDivisionError:
pass


I have to return something that acts like a number but isn't a number.

Something which, once it enters a calculation, should propagate through it.
But not necessarily something which once it enters can never be removed! It
may be that some calculations can "cancel out" these "errors" (indeed, the
atan2 function is one of those -- it can return non-NANs from at least some
NAN arguments). So what should I return? It cannot be a number, but it has
to act like a number. Ideally, it should carry diagnostic information so I
can see what the failure was, for debugging, although I may not bother to
do so that information should at least be available for use.

I have just re-invented NANs.


-- 
Steven

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

Re: Is nan in (nan,) correct?

[Rustom Mody]

On Friday, March 6, 2015 at 10:13:55 PM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:
> 
> > On Friday, March 6, 2015 at 3:57:12 AM UTC+5:30, rand...@fastmail.us
> > wrote:
> >> It's been brought up on Stack Overflow that the "in" operator (on
> >> tuples, and by my testing on dict and list, as well as dict lookup) uses
> >> object identity as a shortcut, and returns true immediately if the
> >> object being tested *is* an element of the container. However, the
> >> contains operation does not specify whether object identity or equality
> >> is to be used. In effect, the built-in container types use a hybrid
> >> test: "a is b or a == b".
> >> 
> >> My question is, is this a *correct* implementation of the operator, or
> >> are objects "supposed to" use a basis of equality for these tests?
> > 
> > nan is an illegal or bogus value.
> 
> NANs *represent* bogus values, they aren't bogus themselves.
> 
> 
> > As usual legalizing the illegal is always fraught with increasing
> > conundrums.
> > 
> > The most (to me) classic instance of this is denotational semantics.
> > In DS one tries to give semantics to programs by mapping programs to
> > math-functions across some domains
> > 
> > However some programs crash. What should be the semantics of such a
> > program. We say its a partial function – undefined at the crash-points.
> > But partial functions are not nearly as tractable (to mathematicians!) as
> > total functions.
> > So we invent a bogus value  ⊥ (called bottom) and totalize all functions
> > by mapping to this.
> > 
> > Very nice…
> > 
> > So nice in fact that we wish to add ⊥ to our programming language
> > 
> > And now all hell breaks loose because the question x == ⊥ is the halting
> > problem.
> 
> Oh nonsense. x == ⊥ is easily performed with the equivalent of:
> 
> type(x) == BottomType and bit_representation(x) == bit_representation(⊥)

You dont grok your theory of computation very well do you?

def foo(x): return x + x
def bar(x): return x + x
def baz(x): return 2*x 

One can imagine an implementation where
id(foo) == id(bar)
[I am assuming that id is a good enough approx to bit_representation]

Can you imagine an implementation where
id(bar) == id(baz) 
?

If you can I will just start increasing the gap between bar and baz
and in that game we will be re-executing the details of the halting problem
(and more generally the Rice theorem)

Simpler for you to revise your Theory of computation I think 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: HELP!! How to ask a girl out with a simple witty Python code??

[Steven D'Aprano]

alister wrote:

> I have not seen one female poster on this site claim to be offended by
> the comment or even consider it to be a slur.


In fairness to Ben, it must be recognised that there are very few women
here, and that is a problem Ben (and I) would like to rectify. We just
disagree on the root cause of that, and whether or not mild put-downs such
as the one in question are part of the cause or not.

(Well, I call it a "mild put-down". Ben may or may not agree that it is
mild.)


-- 
Steven

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

Re: Is nan in (nan,) correct?

[Steven D'Aprano]

random...@fastmail.us wrote:

> On Thu, Mar 5, 2015, at 22:49, Chris Angelico wrote:
>> I'm not sure it's just an optimization. Compare this post from
>> python-dev, where Nick Coghlan discusses the same topic:
>> 
>> https://mail.python.org/pipermail/python-dev/2014-July/135476.html
> 
> If it is a bug for NaN to "infect" containers' behavior, we need to take
> a serious look at sort().

Hmmm. No, I don't think so. I think that NANs are just weird and you either
accept that they do weird things or you don't use them.

Real numbers have a total ordering, so sorting a list of real numbers (or
their closest equivalent in computer implementations) makes sense, and sure
enough we can meaningfully sort a list of finite floats.

Complex numbers do not define an ordering at all: given a complex number w,
and another complex number z, asking whether w < z is meaningless. Ordering
comparisons simply aren't defined for complex numbers at all, and trying to
sort a list with more than one complex number will raise an exception.

But NANs are weird. NANs are unordered like complex, but unlike complex the
order comparisons are defined. They just always return False (except for
not-equal, which always returns True):

NAN < x returns False, for every x
NAN > x also returns False, for every x

If you think of NANs as members of a set with total ordering, like the real
number line, then this doesn't make sense. But floats (as opposed to the
Real Numbers) don't have total order. If you think of NANs as members of
unorderable values like the complex plane, then you should get an
exception, but they aren't members of an unorderable set, they're merely
not ordered. There's nothing wrong with doing:

if x < 1.2345: ...

just because x happens to be a NAN. One shouldn't raise an exception (even
though this is an exceptional case), because < and > operators are
perfectly well-defined for NANs, unlike the case for complex values.

But the consequence of this is that sort misbehaves. Sort algorithms depend
on the values being sorted having a total order. If you sort a list
containing objects with a partial order (like sets, or NANs), then the sort
result is dependent on the initial order of the elements.

If we really wanted to solve this problem, we could re-define sorting to use
a separate method instead of __lt__, let's call it __sort_lt__. If
__sort_lt__ doesn't exist, sorting will fall back on __lt__. That will
allow sets to distinguish between the use of < for subset testing and the
use of < for the purposes of sorting, and raise an exception or a warning.
Likewise floats could define the method:

def __sort_lt__(self, other):
if isnan(self) or isnan(other):
raise SomeException
return type(self).__lt__(other)


Another option would be to have a context manager which disables order
comparisons for NANs:

def sorted(it):
L = list(it)
with disabled_nan_comparisons():
L.sort()  # raise if L contains a NAN
return L

sort of thing.

But either solution is a pretty big change for a pretty rare issue.



-- 
Steven

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

Re: Speeding up permutations generation

[Ian Kelly]

On Fri, Mar 6, 2015 at 1:24 AM, Abhiram R  wrote:
>
>>
>> A list of 100 elements has approximately 9.33 x 10**157 permutations.
>> If you could somehow generate one permutation every yoctosecond,
>> exhausting them would still take more than a hundred orders of
>> magnitude longer than the age of the universe.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>
>
> True that :D I may have exaggerated on the number. Let's consider something
> more practically manageable => 50 elements with a 50! permutation.
> Is there a solution now?

That's still infeasible, as others have pointed out. At one
permutation every picosecond, you'll still need 9.6 x 10**44 years.

If the size isn't that important to you and you just want a faster
implementation of permutations, you could try reimplementing it
yourself as a C extension. The stdlib implementation is already
written in C though, so unless you have a better algorithm I doubt
you'll find much room for optimization.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is nan in (nan,) correct?

[Chris Angelico]

On Sat, Mar 7, 2015 at 4:04 AM, Rustom Mody  wrote:
> You dont grok your theory of computation very well do you?
>
> def foo(x): return x + x
> def bar(x): return x + x
> def baz(x): return 2*x
>
> One can imagine an implementation where
> id(foo) == id(bar)
> [I am assuming that id is a good enough approx to bit_representation]
>
> Can you imagine an implementation where
> id(bar) == id(baz)
> ?

No, I cannot imagine either. Those functions have different
identities. They may be considered *equal* but they should not be
*identical*. I can imagine a language in which they are considered
indistinguishable and optimized down to one, but if you consider them
to be the same function, then you've abolished all concept of
identity.

Also, I have no idea what any of this has to do with nans and
container membership.

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

Re: Is nan in (nan,) correct?

[Rustom Mody]

On Friday, March 6, 2015 at 10:48:07 PM UTC+5:30, Chris Angelico wrote:
> On Sat, Mar 7, 2015 at 4:04 AM, Rustom Mody  wrote:
> > You dont grok your theory of computation very well do you?
> >
> > def foo(x): return x + x
> > def bar(x): return x + x
> > def baz(x): return 2*x
> >
> > One can imagine an implementation where
> > id(foo) == id(bar)
> > [I am assuming that id is a good enough approx to bit_representation]
> >
> > Can you imagine an implementation where
> > id(bar) == id(baz)
> > ?
> 
> No, I cannot imagine either. Those functions have different
> identities. They may be considered *equal* but they should not be
> *identical*. I can imagine a language in which they are considered
> indistinguishable and optimized down to one, but if you consider them
> to be the same function, then you've abolished all concept of
> identity.

Treat id as the python version of bit_representation.
Now we have two things (worlds really)
in-python entities like foo/bar/baz
Their mathematical semantics -- the infinite sets of (domain,range)
pairs that they are intended to capture.
[Jargon note: The id-equal is called intensional-equality the math-equality is
called extensional-equality]

To get foo == bar one can imagine something like
1. Hash the dis of every function
2. If a new function being defined is hash-equal to an old one:
 If dis(new) == dis(old)
make new_name point to old implementation

To make bar == baz we need more and more heavy-duty theorem provers
And will invariably hit halting-problem in some guise or other

> 
> Also, I have no idea what any of this has to do with nans and
> container membership.

⊥ in semantics is the prototypical example of reifying an undefined entity.
As are all the other examples nil/None/nul/nan.

It buys a bigger problem for a smaller one -- Steven's (other thread) example of
"Should I know whether an asteroid the size of Texas is earth bound?"

To take a less apocalyptic example: 
I am holding a bomb in my hand.
Is it good to know that? DOes it help any?
Does the statement "We have a problem!!" make the 'problem' vanish?
⊥/nul/nil/nan are all 'bombs/problems' in some sense
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is nan in (nan,) correct?

[Rustom Mody]

On Friday, March 6, 2015 at 10:29:19 PM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:
> 
> > On Friday, March 6, 2015 at 3:31:58 PM UTC+5:30, Chris Angelico wrote:
> >> On Fri, Mar 6, 2015 at 8:50 PM, Rustom Mody  wrote:
> >> > In a language like python with decent exceptions we do not need nans.
> >> 
> >> Not so. I could perhaps accept that we don't need signalling NaNs, as
> >> they can be replaced with exceptions, but quiet NaNs are by definition
> >> _not_ exceptions.
> > 
> > My impression (maybe I am wrong):
> > "Catch an exception and ignore it" is a way of converting signalling to
> > quiet With the added advantage of being able to tweak the specs of what
> > happens when nan op normal to one's taste
> 
> 
> I don't understand what you are trying to say.
> 
> Let's take a dirt-simple example:
> 
> def inverse(x):
> return 1.0/x
> 
> There's an exception there, waiting to bite. If I include inverse() in some
> complex calculation:
> 
> def function(x, y):
> return atan2(inverse(3*x*y)+1, inverse(1 - x**2 + 3*x - 0.2)**3)
> 
> values = [function(1.5*x, y+2) for x, y in zip(xx, yy)]
> 
> and I just wish to skip over the failed calculations, I can't just "ignore"
> exceptions:
> 
> # This doesn't work!
> def inverse(x):
> try:
> return 1.0/x
> except ZeroDivisionError:
> pass
> 
> 
> I have to return something that acts like a number but isn't a number.
> 
> Something which, once it enters a calculation, should propagate through it.
> But not necessarily something which once it enters can never be removed! It
> may be that some calculations can "cancel out" these "errors" (indeed, the
> atan2 function is one of those -- it can return non-NANs from at least some
> NAN arguments). So what should I return? It cannot be a number, but it has
> to act like a number. Ideally, it should carry diagnostic information so I
> can see what the failure was, for debugging, although I may not bother to
> do so that information should at least be available for use.
> 
> I have just re-invented NANs.

Ok... Maybe so
As I said I am not too sure about this

However you have to give me a little fuller (if not more realistic) example
[Your xx and yy are what?]

And I have to see if I know how to tweak it nan-less
And at least maintain hopefully improve the clarity, succinctness of the 
original!  Not saying I will be able -- just that thats the claim
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is nan in (nan,) correct?

[Ethan Furman]

On 03/06/2015 10:04 AM, Rustom Mody wrote:
> On Friday, March 6, 2015 at 10:29:19 PM UTC+5:30, Steven D'Aprano wrote:

>> def inverse(x):
>> return 1.0/x
>>
>> There's an exception there, waiting to bite. If I include inverse() in some
>> complex calculation:
>>
>> def function(x, y):
>> return atan2(inverse(3*x*y)+1, inverse(1 - x**2 + 3*x - 0.2)**3)
>>
>> values = [function(1.5*x, y+2) for x, y in zip(xx, yy)]

> Ok... Maybe so
> As I said I am not too sure about this
> 
> However you have to give me a little fuller (if not more realistic) example
> [Your xx and yy are what?]

xx and yy are lists of floats, and for your test xx should have at least one 
zero in it.

> And I have to see if I know how to tweak it nan-less
> And at least maintain hopefully improve the clarity, succinctness of the 
> original!  Not saying I will be able -- just that thats the claim

Good luck.  :)

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]

[Marko Rauhamaa]

llanitedave :

> It's obvious that's what's needed here is a PEP requiring that the
> International Phonetic Alphabet be used for all Python identifiers and
> keywords.

You're onto something:


#!/ˈjuːzəɹ/bɪn/ɛnv ˈpaɪˌθɑːn3
# -*- ˈkoʊdɪŋ: ˌjuːˌtiːˌɛf-ˈ8 -*-

ˈɪmpoɹt loʊˈkæl

dɛf meɪn():
tɹaɪ:
ɹeɪz ˈVæljuːˈƐɹəɹ()
ɪkˈsɛpt ˈVæljuːˈƐɹəɹ:
tɹaɪ:
ɹeɪz ˈAɪOʊˈƐɹəɹ()
ˈfaɪnli:
ɹeɪz

ɪf __neɪm__ == "__meɪn__":
tɹaɪ:
meɪn()
ɪkˈsɛpt ˈVæljuːˈƐɹəɹ:
pɹɪnt("Həˈloʊ")



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

Re: Make standalone gui-enabled app for LINUX

[Christian Gollwitzer]

Am 06.03.15 um 09:14 schrieb Mehdi:
> On Friday, March 6, 2015 at 12:58:11 AM UTC+3:30, Christian Gollwitzer wrote:
>> Use pyinstaller. It creates a "portable app", i.e. either single file or
>> directory which can be run on (nearly) any system. However the resulting
>> files can be awfully big. I use it with a relatively small program that
>> depends on numpy/matplolib, and that pulls in ~100 MB worth of libraries.
>
> But i think pyinstaller doesn't work with python3.
>

Oops. you are right. I'm still using Python2. They announced
"experimental python3 support" on the web page, though.

Christian


PS: Quoting fixed.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (Still OT) Nationalism, language and monoculture [was Re: Python Worst Practices]

[Christian Gollwitzer]

Am 06.03.15 um 19:15 schrieb Marko Rauhamaa:
> llanitedave :
> 
>> It's obvious that's what's needed here is a PEP requiring that the
>> International Phonetic Alphabet be used for all Python identifiers and
>> keywords.
> 
> You're onto something:
ROFL!!!
Though I'd prefer a few identifiers in a different way; I think you can
drop many of the ɹ, e.g.

> 
> #!/ˈjuːzəɹ/bɪn/ɛnv ˈpaɪˌθɑːn3
> # -*- ˈkoʊdɪŋ: ˌjuːˌtiːˌɛf-ˈ8 -*-
> 
> ˈɪmpoɹt loʊˈkæl
ɪmˈpɔːt ˈləʊkl

British accent saves bytes!!
SCNR


> 
> dɛf meɪn():
> tɹaɪ:
> ɹeɪz ˈVæljuːˈƐɹəɹ()
> ɪkˈsɛpt ˈVæljuːˈƐɹəɹ:
> tɹaɪ:
> ɹeɪz ˈAɪOʊˈƐɹəɹ()
> ˈfaɪnli:
> ɹeɪz
> 
> ɪf __neɪm__ == "__meɪn__":
> tɹaɪ:
> meɪn()
> ɪkˈsɛpt ˈVæljuːˈƐɹəɹ:
> pɹɪnt("Həˈloʊ")
> 
> 
> 
> Marko
> 

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

Odo: Shapeshifting for your data

[Mark Lawrence]

https://odo.readthedocs.org/en/latest/

I don't know if there is a need for shunting data around in this way but 
some of you may find this interesting.


Now let's see how long it takes to go wonderfully off topic.  I'll give 
it five minutes.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Odo: Shapeshifting for your data

[sohcahtoa82]

On Friday, March 6, 2015 at 12:03:59 PM UTC-8, Mark Lawrence wrote:
> https://odo.readthedocs.org/en/latest/
> 
> I don't know if there is a need for shunting data around in this way but 
> some of you may find this interesting.
> 
> Now let's see how long it takes to go wonderfully off topic.  I'll give 
> it five minutes.
> 
> -- 
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
> 
> Mark Lawrence

Five minutes?  You have too much faith in this list.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Speeding up permutations generation

[Stefan Behnel]

Ian Kelly schrieb am 06.03.2015 um 18:13:
> On Fri, Mar 6, 2015 at 1:24 AM, Abhiram R wrote:
>>> A list of 100 elements has approximately 9.33 x 10**157 permutations.
>>> If you could somehow generate one permutation every yoctosecond,
>>> exhausting them would still take more than a hundred orders of
>>> magnitude longer than the age of the universe.
>>
>> True that :D I may have exaggerated on the number. Let's consider something
>> more practically manageable => 50 elements with a 50! permutation.
>> Is there a solution now?
> 
> That's still infeasible, as others have pointed out. At one
> permutation every picosecond, you'll still need 9.6 x 10**44 years.
> 
> If the size isn't that important to you and you just want a faster
> implementation of permutations, you could try reimplementing it
> yourself as a C extension. The stdlib implementation is already
> written in C though, so unless you have a better algorithm I doubt
> you'll find much room for optimization.

Well, one obvious "optimisation" in a case like this is to change the order
in which permutations are returned. If processing all of them is
infeasible, then being able to control which ones will be processed can be
a crucial property of a "better" algorithm.

Stefan


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

Re: http: connection reset by peer

[Emile van Sebille]

On 3/5/2015 12:18 PM, Chris Angelico wrote:

On Fri, Mar 6, 2015 at 5:37 AM, Ethan Furman  wrote:



After mucking about with it with no results, I went on to another job -- when I 
came back to this one it was working.


Huh. Well, if it recurs, see what you can find out about it...
otherwise, problem solved!


Well, no remaining symptoms.  I don't consider a problem solved if I 
fail to understand the context.


Emile



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

Append a file

[Jason Venneri]

Hello, I'm using the urllib.urlretrieve command to retrieve a couple of lines 
of data.  I want to combine the two results into one file not two.  

Any suggestions?

Sample
urllib.urlretrieve('http://www.airplanes.com/data/boeing1.html','B747A.txt')
urllib.urlretrieve('http://www.airplanes.com/data/boeing2.html','B747B.txt')

I would like one file say B747C that contains the data from B747A and B747B in 
a file named B747C
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Append a file

[sohcahtoa82]

On Friday, March 6, 2015 at 1:55:31 PM UTC-8, Jason Venneri wrote:
> Hello, I'm using the urllib.urlretrieve command to retrieve a couple of lines 
> of data.  I want to combine the two results into one file not two.  
> 
> Any suggestions?
> 
> Sample
> urllib.urlretrieve('http://www.airplanes.com/data/boeing1.html','B747A.txt')
> urllib.urlretrieve('http://www.airplanes.com/data/boeing2.html','B747B.txt')
> 
> I would like one file say B747C that contains the data from B747A and B747B 
> in a file named B747C

What have you tried so far?  Generally on this mailing list, we'll help you 
find what you're doing wrong, but we won't write your script for you.

I'll give you one hint though, you should probably try urllib.urlopen, then 
write the file yourself.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: http: connection reset by peer

[Grant Edwards]

On 2015-03-06, Emile van Sebille  wrote:
> On 3/5/2015 12:18 PM, Chris Angelico wrote:
>> On Fri, Mar 6, 2015 at 5:37 AM, Ethan Furman  wrote:
>
>>> After mucking about with it with no results, I went on to another job
>>> -- when I came back to this one it was working.
>>
>> Huh. Well, if it recurs, see what you can find out about it...
>> otherwise, problem solved!
>
> Well, no remaining symptoms.  I don't consider a problem solved if I 
> fail to understand the context.

In cases like that, I don't call the problem solved.  I prefer to say
that the problem "went away".  :)

-- 
Grant Edwards   grant.b.edwardsYow! I think I am an
  at   overnight sensation right
  gmail.comnow!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: http: connection reset by peer

[Chris Angelico]

On Sat, Mar 7, 2015 at 9:12 AM, Grant Edwards  wrote:
> On 2015-03-06, Emile van Sebille  wrote:
>> On 3/5/2015 12:18 PM, Chris Angelico wrote:
>>> On Fri, Mar 6, 2015 at 5:37 AM, Ethan Furman  wrote:
>>
 After mucking about with it with no results, I went on to another job
 -- when I came back to this one it was working.
>>>
>>> Huh. Well, if it recurs, see what you can find out about it...
>>> otherwise, problem solved!
>>
>> Well, no remaining symptoms.  I don't consider a problem solved if I
>> fail to understand the context.
>
> In cases like that, I don't call the problem solved.  I prefer to say
> that the problem "went away".  :)

It's like with Mythbusters. They ask JD Nelson to help them to make
something 'go away'.

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

Re: HELP!! How to ask a girl out with a simple witty Python code??

[Ben Finney]

Steven D'Aprano  writes:

> (Well, I call it a "mild put-down". Ben may or may not agree that it is
> mild.)

I agree that the put-down is mild, in that the person uttering it
probably doesn't expect it to be more than a mild insult to the person
they were addressing.

That's quite orthogonal to the fact that invoking gender as an insult is
strongly undermining the goal of making our community welcoming to all
genders. That effect on third parties is completely unrelated to the
intended magnitude of the insult.

I'm glad we have common cause. Let's keep calling out harmful crap when
we see it.

-- 
 \ “Airports are ugly. Some are very ugly. Some attain a degree of |
  `\ugliness that can only be the result of a special effort.” |
_o__)   —Douglas Adams, _The Long Dark Tea-Time of the Soul_, 1988 |
Ben Finney

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

Re: Is nan in (nan,) correct?

[Steven D'Aprano]

Rustom Mody wrote:

> On Friday, March 6, 2015 at 10:13:55 PM UTC+5:30, Steven D'Aprano wrote:
>> Rustom Mody wrote:
>> 
>> > On Friday, March 6, 2015 at 3:57:12 AM UTC+5:30, rand...@fastmail.us
>> > wrote:
>> >> It's been brought up on Stack Overflow that the "in" operator (on
>> >> tuples, and by my testing on dict and list, as well as dict lookup)
>> >> uses object identity as a shortcut, and returns true immediately if
>> >> the object being tested *is* an element of the container. However, the
>> >> contains operation does not specify whether object identity or
>> >> equality is to be used. In effect, the built-in container types use a
>> >> hybrid test: "a is b or a == b".
>> >> 
>> >> My question is, is this a *correct* implementation of the operator, or
>> >> are objects "supposed to" use a basis of equality for these tests?
>> > 
>> > nan is an illegal or bogus value.
>> 
>> NANs *represent* bogus values, they aren't bogus themselves.
>> 
>> 
>> > As usual legalizing the illegal is always fraught with increasing
>> > conundrums.
>> > 
>> > The most (to me) classic instance of this is denotational semantics.
>> > In DS one tries to give semantics to programs by mapping programs to
>> > math-functions across some domains
>> > 
>> > However some programs crash. What should be the semantics of such a
>> > program. We say its a partial function – undefined at the crash-points.
>> > But partial functions are not nearly as tractable (to mathematicians!)
>> > as total functions.
>> > So we invent a bogus value  ⊥ (called bottom) and totalize all
>> > functions by mapping to this.
>> > 
>> > Very nice…
>> > 
>> > So nice in fact that we wish to add ⊥ to our programming language
>> > 
>> > And now all hell breaks loose because the question x == ⊥ is the
>> > halting problem.
>> 
>> Oh nonsense. x == ⊥ is easily performed with the equivalent of:
>> 
>> type(x) == BottomType and bit_representation(x) == bit_representation(⊥)
> 
> You dont grok your theory of computation very well do you?
> 
> def foo(x): return x + x
> def bar(x): return x + x
> def baz(x): return 2*x
> 
> One can imagine an implementation where
> id(foo) == id(bar)
> [I am assuming that id is a good enough approx to bit_representation]
> 
> Can you imagine an implementation where
> id(bar) == id(baz)
> ?

Not necessarily if x are floats. But I'll grant you that 2*x and x+x are
computationally equivalent if x is an int. I'll also grant you that there
are other functions which are computationally equivalent to x+x  but
immeasurably more complex, and that for the compiler to recognise all such
functions is equivalent to the halting problem.

What does this have to do with the ability to perform an equality test
against some ⊥ value?

Your argument is analogous to this:

"Somewhere, out in the immensity of space, floats an infinite number of
haystacks. Inside just one of those haystacks is a single tiny needle.
Since it is impossible to locate that needle, it is likewise impossible to
locate this needle I hold between my fingers!"

You have made a claim that None is a reinvention of the ⊥ (bottom) pattern,
and that it is impossible to evaluate x == ⊥ due to the Halting Problem.
Let's put that to the test:

[steve@ando ~]$ python -c "x = 23; print x == None"
False


I was hoping to have time to make a cup of tea while Python tried to solve
the Halting Problem, possibly even to go to the market, do some shopping,
do my house work, watch a movie, and catch a good night's sleep, but it
only took a small fraction of a second for x == None to complete.

I can draw only two possible conclusions:

(1) The halting problem, and therefore Godel's Incompleteness Theorem as
well, are disproven and the very fundamentals of mathematics and logic are
overturned; or

(2) You are mistaken that evaluating x == ⊥ is equivalent to solving the
Halting Problem.


If I were a betting man, I know where I would put my money.



-- 
Steven

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

A strange statement in the bisect documentation?

[Dmitry Chichkov]

I was looking over documentation of the bisect module and encountered the 
following very strange statement there:

>From https://docs.python.org/2/library/bisect.html

...it does not make sense for the bisect() functions to have key or reversed 
arguments because that would lead to an inefficient design (successive calls to 
bisect functions would not "remember" all of the previous key lookups).

Instead, it is better to search a list of precomputed keys to find the index of 
the record in question...


Is that right that the documentation encourages to use O(N) algorithm [by 
making a copy of all keys] instead of using O(log(N)) bisect with 
kay=attrgetter?  And claims that O(N) is more efficient than O(log(N))?  

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

Re: A strange statement in the bisect documentation?

[Steven D'Aprano]

Dmitry Chichkov wrote:

> I was looking over documentation of the bisect module and encountered the
> following very strange statement there:
> 
> From https://docs.python.org/2/library/bisect.html
> 
> ...it does not make sense for the bisect() functions to have key or
> reversed arguments because that would lead to an inefficient design
> (successive calls to bisect functions would not "remember" all of the
> previous key lookups).
> 
> Instead, it is better to search a list of precomputed keys to find the
> index of the record in question...
> 
> 
> Is that right that the documentation encourages to use O(N) algorithm [by
> making a copy of all keys] instead of using O(log(N)) bisect with
> kay=attrgetter?  And claims that O(N) is more efficient than O(log(N))?

Apparently :-)


The documentation may not be completely clear, but what it is arguing is
this:

If you are making repeated bisect calls, then using a key function is
inefficient because the key gets lost after each call and has to be
recalculated over and over again. A concrete example:

data = [i/100 for i in range(1, 701, 7)]
data.sort(key=str)

for x in many_x_values:
bisect.insort(data, x, key=str)  # Pretend this works.


The first time you call insort, the key function (str in this case) will be
called O(log N) times. The second time you call insort, the key function
must be called again, even for the same data points, because the keys
str(x) are thrown away and lost after each call to insort.

After M calls to insort, there will have been on average M*(log(N)+1) calls
to the key function. (The +1 is because the x gets str'ed as well, and
there are M loops.)



As an alternative, suppose we do this:

data = [i/100 for i in range(1, 701, 7)]
data.sort(key=str)
keyed_data = [str(x) for x in data]

for x in many_x_values:
key = str(x)
pos = bisect.bisect(keyed_data, key)
keyed_data.insert(pos, key)
data.insert(pos, x)


This costs N calls to str in preparing the keyed_data list, plus M calls to
str in the loop. The documentation suggests that we consider this will be
cheaper in the long run, in other words:

N + M < M*(log(N) + 1)

N + M < M + M*log(N)


That's true whenever N < M*log(N). 

The documentation assumes we should care about large N and large M. As they
say, "everything is fast for small N": if you are doing three bisections on
a list with ten items, then *who cares* how you do it, it's going to be
quite fast. So let's say you have a list of 1 items, that is N = 1.
Then it is faster to build a second keyed_list when:

1 < M*log(1) = M*13  # approximately

i.e. M > 770 give or take. That's a fairly small number, and it's only about
8% of the size of N.

So the general perspective is:

If you have a list of N items, and you call bisect more than about (10% of
N) times, it will likely be faster to pre-prepare a keyed list than call a
key function repeatedly for each call to bisect.

If you call bisect less than (10% of N) times, then it doesn't matter,
because that's comparatively a small number and will be fast enough either
way.


Is the documentation correct? I don't know. I don't have an opinion on this.
I recommend that you fork the bisect module, call it mybisect, add a key
function parameter, and compare the speed of the two versions, with or
without a key function. Remember:

- Recent versions of bisect have a C accelerated version. Make sure you
disable that, so you are comparing the speed of Python versus Python not
Python versus C.

- Nobody will care about small lists. I suggest that you start with at least
ten thousand items, and move up to ten billion or so. For each N in (10**4,
10**5, ... 10**10) find out how many calls to insort or bisect does it take
before the key function version becomes slower. Or possibly faster.

- Is there are difference between fast key functions like str, and slow ones
that have to do a lot of processing?



-- 
Steven

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

Re: Is nan in (nan,) correct?

[Rustom Mody]

On Saturday, March 7, 2015 at 5:04:02 AM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:
> 
> > On Friday, March 6, 2015 at 10:13:55 PM UTC+5:30, Steven D'Aprano wrote:
> >> Rustom Mody wrote:
> >> 
> >> > On Friday, March 6, 2015 at 3:57:12 AM UTC+5:30, rand...@fastmail.us
> >> > wrote:
> >> >> It's been brought up on Stack Overflow that the "in" operator (on
> >> >> tuples, and by my testing on dict and list, as well as dict lookup)
> >> >> uses object identity as a shortcut, and returns true immediately if
> >> >> the object being tested *is* an element of the container. However, the
> >> >> contains operation does not specify whether object identity or
> >> >> equality is to be used. In effect, the built-in container types use a
> >> >> hybrid test: "a is b or a == b".
> >> >> 
> >> >> My question is, is this a *correct* implementation of the operator, or
> >> >> are objects "supposed to" use a basis of equality for these tests?
> >> > 
> >> > nan is an illegal or bogus value.
> >> 
> >> NANs *represent* bogus values, they aren't bogus themselves.
> >> 
> >> 
> >> > As usual legalizing the illegal is always fraught with increasing
> >> > conundrums.
> >> > 
> >> > The most (to me) classic instance of this is denotational semantics.
> >> > In DS one tries to give semantics to programs by mapping programs to
> >> > math-functions across some domains
> >> > 
> >> > However some programs crash. What should be the semantics of such a
> >> > program. We say its a partial function – undefined at the crash-points.
> >> > But partial functions are not nearly as tractable (to mathematicians!)
> >> > as total functions.
> >> > So we invent a bogus value  ⊥ (called bottom) and totalize all
> >> > functions by mapping to this.
> >> > 
> >> > Very nice…
> >> > 
> >> > So nice in fact that we wish to add ⊥ to our programming language
> >> > 
> >> > And now all hell breaks loose because the question x == ⊥ is the
> >> > halting problem.
> >> 
> >> Oh nonsense. x == ⊥ is easily performed with the equivalent of:
> >> 
> >> type(x) == BottomType and bit_representation(x) == bit_representation(⊥)
> > 
> > You dont grok your theory of computation very well do you?
> > 
> > def foo(x): return x + x
> > def bar(x): return x + x
> > def baz(x): return 2*x
> > 
> > One can imagine an implementation where
> > id(foo) == id(bar)
> > [I am assuming that id is a good enough approx to bit_representation]
> > 
> > Can you imagine an implementation where
> > id(bar) == id(baz)
> > ?
> 
> Not necessarily if x are floats. But I'll grant you that 2*x and x+x are
> computationally equivalent if x is an int. I'll also grant you that there
> are other functions which are computationally equivalent to x+x  but
> immeasurably more complex, and that for the compiler to recognise all such
> functions is equivalent to the halting problem.

Good so far

> 
> What does this have to do with the ability to perform an equality test
> against some ⊥ value?

What do you understand by ⊥ value?

> 
> Your argument is analogous to this:
> 
> "Somewhere, out in the immensity of space, floats an infinite number of
> haystacks. Inside just one of those haystacks is a single tiny needle.
> Since it is impossible to locate that needle, it is likewise impossible to
> locate this needle I hold between my fingers!"

Straw... er Hayman!

> 
> You have made a claim that None is a reinvention of the ⊥ (bottom) pattern,

Ok

> and that it is impossible to evaluate x == ⊥ due to the Halting Problem.

That depends on how you answer my question above: What do mean by ⊥ value?

> Let's put that to the test:
> 
> [steve@ando ~]$ python -c "x = 23; print x == None"
> False
> 
> 
> I was hoping to have time to make a cup of tea while Python tried to solve
> the Halting Problem, possibly even to go to the market, do some shopping,
> do my house work, watch a movie, and catch a good night's sleep, but it
> only took a small fraction of a second for x == None to complete.

You dont know the difference between analogy and identity?

> 
> I can draw only two possible conclusions:
> 
> (1) The halting problem, and therefore Godel's Incompleteness Theorem as
> well, are disproven and the very fundamentals of mathematics and logic are
> overturned; or
> 
> (2) You are mistaken that evaluating x == ⊥ is equivalent to solving the
> Halting Problem.
> 
> 
> If I were a betting man, I know where I would put my money.
> 


I'd put my money on (some variation of) "Syntax Error"

python3:

>>> x = 1
>>> x == ⊥
  File "", line 1
x == ⊥
 ^
SyntaxError: invalid character in identifier



python2
>>> x = 1
>>> x == ⊥
  File "", line 1
x == ⊥
 ^
SyntaxError: invalid syntax

Which is to say ⊥ does not exist in python.

So until you say what *you* mean by ⊥ we cannot evaluate where the rheostat 
sits between

"You/I are wrong"  … "You/I are confused" … "You/I are not even wrong"

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

Re: Odo: Shapeshifting for your data

[Steve Hayes]

On Fri, 06 Mar 2015 20:03:07 +, Mark Lawrence
 wrote:

>https://odo.readthedocs.org/en/latest/
>
>I don't know if there is a need for shunting data around in this way but 
>some of you may find this interesting.

That looks very interesting indeed. 

What wasn't clear is whether odo is something you have to download
somewhere. 


-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Odo: Shapeshifting for your data

[Mark Lawrence]

On 07/03/2015 04:42, Steve Hayes wrote:

On Fri, 06 Mar 2015 20:03:07 +, Mark Lawrence
 wrote:


https://odo.readthedocs.org/en/latest/

I don't know if there is a need for shunting data around in this way but
some of you may find this interesting.


That looks very interesting indeed.

What wasn't clear is whether odo is something you have to download
somewhere.



https://pypi.python.org/pypi/odo/0.3.0

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: HELP!! How to ask a girl out with a simple witty Python code??

[Gregory Ewing]

alister wrote:
a popular UK soap made an extreme 
effort not to show a cross or Christmas tree during a church wedding in 
case it "offended not-Christians".


In today's climate, when offending certain varieties
of non-Christian can get you blown up or shot, it might
not be quite as silly as it sounds.

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

Re: HELP!! How to ask a girl out with a simple witty Python code??

[Rustom Mody]

On Saturday, March 7, 2015 at 10:36:54 AM UTC+5:30, Gregory Ewing wrote:
> alister wrote:
> > a popular UK soap made an extreme 
> > effort not to show a cross or Christmas tree during a church wedding in 
> > case it "offended not-Christians".
> 
> In today's climate, when offending certain varieties
> of non-Christian can get you blown up or shot, it might
> not be quite as silly as it sounds.
> 
> -- 
> Greg

Best we know, stupidity and geography dont correlate.

Likewise stupidity and religious affiliation:
http://rmitz.org/freebsd.daemon.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Append a file

[Jason Friedman]

On Fri, Mar 6, 2015 at 2:55 PM, Jason Venneri  wrote:
> Hello, I'm using the urllib.urlretrieve command to retrieve a couple of lines 
> of data.  I want to combine the two results into one file not two.
>
> Any suggestions?
>
> Sample
> urllib.urlretrieve('http://www.airplanes.com/data/boeing1.html','B747A.txt')
> urllib.urlretrieve('http://www.airplanes.com/data/boeing2.html','B747B.txt')
>
> I would like one file say B747C that contains the data from B747A and B747B 
> in a file named B747C

>>> f = open("B747C.txt", "w")
>>> look_for = "Aircraft,"
>>> for line in open("B747A.txt"):
... if look_for in line:
... f.write(line)
...
>>> for line in open("B747B.txt"):
... if look_for in line:
... f.write(line)
...
>>> f.close()

Seems like you are using Python 2, you ought to consider Python 3.

The requests module
(http://docs.python-requests.org/en/latest/user/install/) makes this
kind of work easier.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie question about text encoding

[Terry Reedy]

On 3/6/2015 11:20 AM, Rustom Mody wrote:


=
pp = "💩"
print (pp)
=
Try open it in idle3 and you get (at least I get):

$ idle3 ff.py
Traceback (most recent call last):
   File "/usr/bin/idle3", line 5, in 
 main()
   File "/usr/lib/python3.4/idlelib/PyShell.py", line 1562, in main
 if flist.open(filename) is None:
   File "/usr/lib/python3.4/idlelib/FileList.py", line 36, in open
 edit = self.EditorWindow(self, filename, key)
   File "/usr/lib/python3.4/idlelib/PyShell.py", line 126, in __init__
 EditorWindow.__init__(self, *args)
   File "/usr/lib/python3.4/idlelib/EditorWindow.py", line 294, in __init__
 if io.loadfile(filename):
   File "/usr/lib/python3.4/idlelib/IOBinding.py", line 236, in loadfile
 self.text.insert("1.0", chars)
   File "/usr/lib/python3.4/idlelib/Percolator.py", line 25, in insert
 self.top.insert(index, chars, tags)
   File "/usr/lib/python3.4/idlelib/UndoDelegator.py", line 81, in insert
 self.addcmd(InsertCommand(index, chars, tags))
   File "/usr/lib/python3.4/idlelib/UndoDelegator.py", line 116, in addcmd
 cmd.do(self.delegate)
   File "/usr/lib/python3.4/idlelib/UndoDelegator.py", line 219, in do
 text.insert(self.index1, self.chars, self.tags)
   File "/usr/lib/python3.4/idlelib/ColorDelegator.py", line 82, in insert
 self.delegate.insert(index, chars, tags)
   File "/usr/lib/python3.4/idlelib/WidgetRedirector.py", line 148, in __call__
 return self.tk_call(self.orig_and_operation + args)
_tkinter.TclError: character U+1f4a9 is above the range (U+-U+) allowed 
by Tcl

So who/what is broken?


tcl
The possible workaround is for Idle to translate "💩" to "\U0001f4a9" 
(10 chars) before sending it to tk.


But some perspective.  In the console interpreter:

>>> print("\U0001f4a9")
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Programs\Python34\lib\encodings\cp437.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\U0001f4a9' 
in posit

ion 0: character maps to 

So what is broken?  Windows Command Prompt.

More perspective.  tk/Idle *will* print *something* for every BMP char. 
 Command Prompt will not.  It does not even do ucs-2 correctly. So 
which is more broken?  Windows Command Prompt.  Who has perhaps 
1,000,000 times more resources, Microsoft? or the tcl/tk group?  I think 
we all know.


--
Terry Jan Reedy


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

Re: Python Worst Practices

[Thomas Rachel]

Am 26.02.2015 01:37 schrieb Chris Angelico:


My bad. I was talking in a context of Python programming, specifically
with APIs where you would use some kind of true/false flag as either a
function parameter or a return value.


Oh. Then take subprocess.Popen.wait()... :-P


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