[no subject]

[Ezra Simms]

I cannot seem to get pymongo to find my python installation – keep getting an 
error saying pythin has not been found in the registry? Why is this.

Sent from Mail for Windows 10

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

Hi Im having a problem with python it keeps telling me I need a python interpreter installed Im using windows 10. Can you help?

[mrihustle12]

Sent from my Sprint Samsung Galaxy S® 6.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Loading error message

[Arie van Wingerden]

I saw similar errors when using PyInstaller.
It has something to do with Windows 10 afaik.


2016-03-13 14:17 GMT+01:00 BobFtz--- via Python-list :

> Hello
>
> I have just downloaded and installed a copy of the 3.5.1 programme but when
>  I come to run the programme I get an error message that says that
> .api-ms-win-crt-runtime-l 1-1-0.dll is missing.
>
> I have un-installed and reinstalled the 3.5.1 programme a few time (as
> advised) but I still can't get the programme to run
>
> Can you please help with some step by step advice on how to repair this
> problem.
>
> Many thanks
>
> Bob
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Interaction between pygame and python

[Tyson]

I am having a lot of trouble getting python to find the pygame module; my
operating system is Windows 7.  Can you  offer any help?  . Should I
download pygame into the same folder as Python? . any ideas at all?

 

Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:38:48) [MSC v.1900 32 bit
(Intel)] on win32

Type "copyright", "credits" or "license()" for more information.

>>> import pygame

Traceback (most recent call last):

  File "", line 1, in 

   import pygame

ImportError: No module named 'pygame'

>>> import pygame, sys

Traceback (most recent call last):

  File "", line 1, in 

import pygame, sys

ImportError: No module named 'pygame'

>>> 

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

ABI name tag for libpython

[Robert Snoeberger]

On Debian, the shared library, libpython3.4m.so, is ABI version tagged with an 
“m.” I’m assuming that this is the ABI version tag specified in PEP 3149. The 
PEP give an example of using sysconfig.get_config_var to get the name tag.

>>> sysconfig.get_config_var('SOABI')
'cpython-34m'

I’ve also noticed that the configure variable ‘LDVERSION' gives the ‘3.4m’ bit 
in the library name.

>>> sysconfig.get_config_var('LDVERSION')
‘3.4m'

My question is, are these configure variables a reliable way to determine the 
name tag of the python shared library? I’m trying to use 
ctypes.util.find_library to find libpython.

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

EuroPython 2016: Talk voting is open

[M.-A. Lemburg]

We have more than 280 great proposals for talks and trainings ready
for EuroPython 2016 attendees to vote on.

Please note that you have to have a ticket for EuroPython 2016, or
have submitted a talk proposal yourself, in order to participate.


  ​Attendees: This is your chance to
shape the conference !


You can search for topics and communicate your personal interest by
casting your vote for each talk and training submission on our talk
voting page:


*** https://ep2016.europython.eu/en/talk-voting/ ***

   Talk Voting

   Talk voting will be open until Sunday, March 20.


The program workgroup (WG) will then use the talk voting results as
basis for their talk selection and announce the list of accepted talks
late in March and the schedule shortly thereafter in April.


With gravitational regards,
--
EuroPython 2016 Team
http://ep2016.europython.eu/
http://www.europython-society.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Hi Im having a problem with python it keeps telling me I need a python interpreter installed Im using windows 10. Can you help?

[Sibylle Koczian]

Am 13.03.2016 um 20:19 schrieb mrihustle12:


Sent from my Sprint Samsung Galaxy S® 6.



Not with this information, we'd need much more. The OS is necessary 
information, but not sufficient.


Have you got Python installed? If yes, which version? Where did you get 
it and how did you install it?


I rather suspect you try to run some application that would need Python, 
but Python itself is not installed. Right or wrong?


HTH
Sibylle


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

Re: pdf version of python tutorial

[Jesper K Brogaard]

Den 13-03-2016 kl. 14:45 skrev kamaraju kusumanchi:

Is there a pdf version of the python tutorial
https://docs.python.org/3/tutorial/index.html that I can download? The
idea is to have everything in one file so I can search easily, be able
to work offline.

thanks
raju



Try here: https://docs.python.org/3.5/download.html.

I found the tutorial in the zip-file "PDF(A4 paper size)", which 
contains a lot of PDFs, amongst these many of howto-documents.



--
Venlig hilsen / Best regards
Jesper K. Brogaard

(remove upper case letters in my e-mail address)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Loading error message

[Arie van Wingerden]

Hi Oscar,

that is weird. I am using Windows 10 and get exactly the same "warnings"
when I run PyInstaller.
But the update you mention is only available for up to Windows 8.1.

What about Windows 10 then??

Best,
   Arie

2016-03-13 19:52 GMT+01:00 Oscar Benjamin :

> On 13 Mar 2016 17:06, "BobFtz--- via Python-list" 
> wrote:
> >
> > Hello
> >
> > I have just downloaded and installed a copy of the 3.5.1 programme but
> when
> >  I come to run the programme I get an error message that says that
> > .api-ms-win-crt-runtime-l 1-1-0.dll is missing.
> >
> > I have un-installed and reinstalled the 3.5.1 programme a few time (as
> > advised) but I still can't get the programme to run
> >
> > Can you please help with some step by step advice on how to repair this
> > problem.
>
> You need to install a Windows update from Microsoft:
> https://support.microsoft.com/en-us/kb/2999226
>
> Really the installer download page should be updated with this information
> and the installer should be improved to give a more informative error
> message.
>
> --
> Oscar
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 14/03/2016 03:01, Steven D'Aprano wrote:

On Mon, 14 Mar 2016 12:16 am, BartC wrote:



Worth having but at significant cost. But look at my jpeg test (look at
any other similar programs); how many function names are used
dynamically? How many functions *really* need to be dynamic?


As difficult as it may seem sometimes, Python is not a specialist
programming language designed to be optimal for your jpeg test, it is a
general purpose programming language designed for many different uses :-)


jpeg is an example of the sort of program that many, many people are 
writing. The sort where you write a bunch of functions, and you write 
code that calls them.


Sometimes, you need to call a function indirectly, or need a table of 
functions, or need to pass a function as an argument, but that's 
possible /without having to rename functions/. Even C can do all this.



there seems to be just one kind. The
different categories (function, variable, class, built-in, module etc)
are sorted out at *run-time*.


What do you mean by "sorted out"?


Well, in the case of executing f(a,b,x=c), then runtime will do the 
lookup of f, check the number of arguments, sort out that keyword 
argument, all that stuff.


That could be done at compile-time (ie. the byte-code compiler) if the 
compiler had sight of the definition of f, and it knew for sure the f in 
f() referred to that definition.


> You have names in a namespace which are
> bound to objects. Once you have bound a name, you can rebind it:


At compile time, you don't in general know what value things will have. You
don't even know what type they will have (since the type of an object is
part of its value).


That's true of *variables*. It needn't be true of *functions* and 
*modules* and *classes* because you've told the compiler exactly what 
they are!


If you want to do this with functions, I've already shown a few times a 
technique where you split the function name used with 'def' into two: a 
fixed static name and a dynamic name, a 'pointer' initially referring to 
this function, that can later be assigned something else. If you have to.



Here is an extreme example to demonstrate the difficulty:


import random
if random.random() < 0.5:
 def f():
 return 1
else:
 f = "hello"

f = "goodbye"


So tell me: *at compile time*, how do you know whether the final binding
(assignment of "goodbye" to variable f) should be allowed or not?


First, let me try and emulate that exact behaviour in a 'crippled' 
language that doesn't allow function rebinding:


function f1= {return 1}

if random(1)<0.5 then
  f:=f1
else
  f:="hello
fi

f:="goodbye"


So the question doesn't come up; we're simply dealing with variables. 
The actual function (the name that permanently refers to the code 
'return 1', or 'f1' in my example) doesn't change.



I don't think you are, but let's suppose you're right and that the compiler
can reliably detect and prevent code like this:

def f(): return 1
g = f
g = something_else  # allowed
f = something_else  # not allowed


Are we talking about some imaginary version of Python where the ability 
to re-bind function, module and class names hadn't been allowed?


Then you would simply tweak the code so that 'f' the variable and 'f' 
the actual function are different names.


Or how you change Python now to have both fixed function names yet allow 
all these manipulations?


I don't know. People don't seem to like adding annotations such as:

static def f(): return 1

which would force you to create an alias for f as I said above:

static def _f(): return 1
f = _f


How do you intend to prevent this?

def f(): return 1
exec "f = something_else"


(I don't use exec or eval, and have never seriously implemented them. In 
fact I wrote these comments once in comp.programming a few years back:


>> Perhaps an "Eval Index" can be created which measures how much Eval
>> slows down a language: the bigger the slow-down, then the more
>> efficient would be the language. And it could be measured by putting
>> Eval "" around every line or statement (or smallest unit of
>> which Eval can make sense) of a benchmark program and seeing how
>> much it slows down.
>>
>> (And something like Lisp I'd imagine would have an Eval Index of 1.0
>> :-)  )

But to get back to your question: same answer as above.


Suppose we removed the ability to rebind names that were bound to a
function, as you suggest. There's a very important and commonplace use for
rebinding functions that we would lose: decorators.



But there are times where you
cannot use decorator syntax, and have to write it the old-school way:

func = decorate(func)


I can't see a problem here. Just a minor bit of renaming needed. 
(Although I don't understand whatever else decorators too.)


Yes, there's a bit of inconvenience when you're importing a library 
where you're not allowed to re-bind the functions inside it, so that you 
can use the same name to mean something different.


But 

Re: Interaction between pygame and python

[Ian Kelly]

On Mar 14, 2016 2:34 AM, "Tyson"  wrote:
>
> I am having a lot of trouble getting python to find the pygame module; my
> operating system is Windows 7.  Can you  offer any help?  . Should I
> download pygame into the same folder as Python? . any ideas at all?

In what form did you download PyGame? If you downloaded an installer, just
run it. If you downloaded a zip or other archive, extract it into a
temporary folder and run the setup.py script inside. If you downloaded a
whl file, then run "pip install " from the Windows command prompt.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Simple exercise

[Rick Johnson]

On Thursday, March 10, 2016 at 7:22:26 PM UTC-6, Mark Lawrence wrote:
> Always a code smell when range() and len() are combined.

I would be careful about dealing in absolutes Mark. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Simple exercise

[Larry Martell]

On Mon, Mar 14, 2016 at 10:07 AM, Rick Johnson
 wrote:
> On Thursday, March 10, 2016 at 7:22:26 PM UTC-6, Mark Lawrence wrote:
>> Always a code smell when range() and len() are combined.
>
> I would be careful about dealing in absolutes Mark.

I always think people should never use absolutes.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Simple exercise

[alister]

On Mon, 14 Mar 2016 07:07:45 -0700, Rick Johnson wrote:

> On Thursday, March 10, 2016 at 7:22:26 PM UTC-6, Mark Lawrence wrote:
>> Always a code smell when range() and len() are combined.
> 
> I would be careful about dealing in absolutes Mark.

a code smell does not necesarily mean the code is wrong, just that it 
warrents investigation as thre is a strog possibility it may be sub-
optimal



-- 
Andries Brouwer wrote:
> Linux is unreliable.
> That is bad.

Since your definition of reliability is a mathematical abstraction 
requiring
infinite storage why don't you start by inventing infinitely large SDRAM
chips, then get back to us ?

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

Re: Simple exercise

[Rick Johnson]

On Thursday, March 10, 2016 at 8:04:04 PM UTC-6, Mark Lawrence wrote:
> On 11/03/2016 01:45, BartC wrote:
> > [...]
> > Any other way of traversing two lists in parallel?
> >
>
> Use zip()

Sure, the zip function is quite handy, but it can produce
subtle bugs when both sequences are not of the same length.
Consider the following:

# BEGIN INTERACTIVE SESSION
>>> a = [1,2,3]
>>> b = list('abcde')
>>> for _ in zip(a, b):
... print(_)
(1, 'a')
(2, 'b')
(3, 'c')
# END INTERACTIVE SESSION

Hey kids, the letter of the day is "e" , and the noun of the
day is "ether", and the verb of the day is, you guessed it:
"evaporate"!

I would strongly warn anyone against using the zip function
unless they are absolutely, one hundred percent, not
guilty... urm, oops, sorry to steal your line OJ. And BTW,
did you ever find your wife's killer? But i digress.

I meant to say: absolutely, one hundred percent *SURE*, that
both sequences are of the same length, or, absolutely one
hundred percent *SURE*, that dropping values is not going to
matter. For that reason, i avoid the zip function like the
plague. I would much rather get an index error, than let an
error pass silently.

PS: Hmm, why does that last sentence have such a familiar
"ring" to it?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is anyone in this group using Python Editor v5 for Chromebooks?

[Ian Kelly]

On Sun, Mar 13, 2016 at 5:00 PM, Jeff Schumaker  wrote:
> I'm trying to use Python Editor v5 for Chromebooks. It works fine, except it 
> won't read data files. I'm just wondering if anyone else is using this editor 
> and has found a solution to this problem.

Sorry, haven't tried it. On my Chromebook I SSH into a Linux host and
use Emacs for code editing. I also use Crouton to run Ubuntu Linux in
a chroot shell on my Chromebook, so I can run a native Python locally
when I want, but I still just use Emacs for that.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 13/03/2016 09:39, Steven D'Aprano wrote:

On Sun, 13 Mar 2016 04:54 am, BartC wrote:



Common sense tells you it is unlikely.


Perhaps your common sense is different from other people's common sense. To
me, and many other Python programmers, it's common sense that being able to
replace functions or methods on the fly is a useful feature worth having.
More on this below.

Perhaps this is an example of the "Blub Paradox":


Perhaps it's time to talk about something which many languages have, but 
Python hasn't. Not as far as I know anyway.


That's references to names (sometimes called pointers). So if I write:

 a = 100
 f(a)

then function f gets passed the value that a refers to, or 100 in this 
case. But how do you pass 'a' itself?


Perhaps you can say:

  f('a')

and f can do some sort of lookup, if it knows the caller's context, for 
such a name and retrieve the value that way. But that's rather 
heavy-handed, and f can't distinguish between a reference to a name, and 
a string.


Unless maybe you wrap this up in a class and  Well, you end up with 
something that might emulate a name reference, but with so much 
complexity and such overheads that it is not worthwhile.


Yet, this is a feature I use extensively, far more often than I would 
use mutable functions. And in fact it was used in the code for my jpeg 
example, where in the Python I has to use a workaround (see below).


I would argue that such references are more useful than mutable function 
names, as the latter can be more easily emulated and with little or no 
extra overheads.


-

Non-Python example of reference parameters:

fastidct8(
block[j],  # each argument can be updated by the callee
block[j+8],
block[j+16],
block[j+24],
block[j+32],
block[j+40],
block[j+48],
block[j+56])

proc fastidct8(&a1,&a2,&a3,&a4,&a5,&a6,&a7,&a8) =
const w1 = 2841  # (Incidentally, here's a use-case for proper
const w2 = 2676  # consts. Evaluated at compile-time here ...
const w3 = 2408
const w5 = 1609
const w6 = 1108
const w7 = 565

a1 := (x8 + x2) >> 8
a2 := (x4 + x3) >> 8
a3 := (x1 + x5) >> 8
a4 := (x9 + x7) >> 8
a5 := (x9 - x7) >> 8
a6 := (x1 - x5) >> 8
a7 := (x4 - x3) >> 8
a8 := (x8 - x2) >> 8
end

Python version:

(block[j],
 block[j+8],
 block[j+16],
 block[j+24],
 block[j+32],
 block[j+40],
 block[j+48],
 block[j+56]) = fastidct8(
block[j],
block[j+8],
block[j+16],
block[j+24],
block[j+32],
block[j+40],
block[j+48],
block[j+56])

def fastidct8(a1,a2,a3,a4,a5,a6,a7,a8):
w1 = 2841   #  ... but at run-time in here)
w2 = 2676
w3 = 2408
w5 = 1609
w6 = 1108
w7 = 565

a1 = (x8 + x2) >> 8
a2 = (x4 + x3) >> 8
a3 = (x1 + x5) >> 8
a4 = (x9 + x7) >> 8
a5 = (x9 - x7) >> 8
a6 = (x1 - x5) >> 8
a7 = (x4 - x3) >> 8
a8 = (x8 - x2) >> 8
return [a1,a2,a3,a4,a5,a6,a7,a8]

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

Re: Loading error message

[Arie van Wingerden]

Hi,

I could solve the problem on Windows 10 this way:
   - install Windows 10 stand alone sdk
https://dev.windows.com/en-us/downloads/windows-10-sdk
   - add this dir to PATH: C:\Program Files (x86)\Windows
Kits\10\Redist\ucrt\DLLs\x86

HTH,
   Arie

2016-03-14 13:07 GMT+01:00 Arie van Wingerden :

> Hi Oscar,
>
> that is weird. I am using Windows 10 and get exactly the same "warnings"
> when I run PyInstaller.
> But the update you mention is only available for up to Windows 8.1.
>
> What about Windows 10 then??
>
> Best,
>Arie
>
> 2016-03-13 19:52 GMT+01:00 Oscar Benjamin :
>
>> On 13 Mar 2016 17:06, "BobFtz--- via Python-list" > >
>> wrote:
>> >
>> > Hello
>> >
>> > I have just downloaded and installed a copy of the 3.5.1 programme but
>> when
>> >  I come to run the programme I get an error message that says that
>> > .api-ms-win-crt-runtime-l 1-1-0.dll is missing.
>> >
>> > I have un-installed and reinstalled the 3.5.1 programme a few time (as
>> > advised) but I still can't get the programme to run
>> >
>> > Can you please help with some step by step advice on how to repair this
>> > problem.
>>
>> You need to install a Windows update from Microsoft:
>> https://support.microsoft.com/en-us/kb/2999226
>>
>> Really the installer download page should be updated with this information
>> and the installer should be improved to give a more informative error
>> message.
>>
>> --
>> Oscar
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Loading error message

[Oscar Benjamin]

On 14 March 2016 at 12:07, Arie van Wingerden  wrote:
> that is weird. I am using Windows 10 and get exactly the same "warnings"
> when I run PyInstaller.
> But the update you mention is only available for up to Windows 8.1.
>
> What about Windows 10 then??

I'm not sure what you mean. Windows 10 should already have the UCRT so
it shouldn't need the update. Is it possibly a bug in pyinstaller?
What exactly are you doing to see this error message?

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

Re: Simple exercise

[Oscar Benjamin]

On 14 March 2016 at 14:35, Rick Johnson  wrote:
>
> I would strongly warn anyone against using the zip function
> unless
...
> I meant to say: absolutely, one hundred percent *SURE*, that
> both sequences are of the same length, or, absolutely one
> hundred percent *SURE*, that dropping values is not going to
> matter. For that reason, i avoid the zip function like the
> plague. I would much rather get an index error, than let an
> error pass silently.

I also think it's unfortunate that zip silently discards items. Almost
always when I use zip I would prefer to see an error when the two
iterables are not of the same length. Of course you're not necessarily
safer with len and range:

a = [1, 2, 3]
b = 'abcde'

for n in range(len(a)):
print(a[n], b[n])

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

Re: Simple exercise

[Ian Kelly]

On Mon, Mar 14, 2016 at 9:06 AM, Oscar Benjamin
 wrote:
> On 14 March 2016 at 14:35, Rick Johnson  wrote:
>>
>> I would strongly warn anyone against using the zip function
>> unless
> ...
>> I meant to say: absolutely, one hundred percent *SURE*, that
>> both sequences are of the same length, or, absolutely one
>> hundred percent *SURE*, that dropping values is not going to
>> matter. For that reason, i avoid the zip function like the
>> plague. I would much rather get an index error, than let an
>> error pass silently.
>
> I also think it's unfortunate that zip silently discards items. Almost
> always when I use zip I would prefer to see an error when the two
> iterables are not of the same length.

It's sometimes very useful, though. For example on multiple occasions
I've taken advantage of the fact that enumerate(x) is equivalent to
zip(itertools.count(), x). If zip raised an error then that would only
be possible using islice, and then only if the length is known in
advance.

Also, in order for zip to know that the lengths are not equal, it
would have to try to read one additional item from the longer
iterable. That's rather unfortunate if it's an iterator and you're
hoping to catch the exception and then use the rest of the iterator
for something else.
-- 
https://mail.python.org/mailman/listinfo/python-list

Missing something about timezones

[Skip Montanaro]

Is this correct (today, with Daylight Savings in effect)?

>>> import pytz
>>> i.timezone
'America/Chicago'
>>> pytz.timezone(i.timezone)

>>> ot
datetime.datetime(2016, 3, 14, 9, 30, tzinfo=)
>>> ot.tzinfo


Shouldn't the America/Chicago timezone reflect DST?

Thx,

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

Re: looping and searching in numpy array

[Oscar Benjamin]

On 10 March 2016 at 13:02, Peter Otten <__pete...@web.de> wrote:
> Heli wrote:
>
>> I need to loop over a numpy array and then do the following search. The
>> following is taking almost 60(s) for an array (npArray1 and npArray2 in
>> the example below) with around 300K values.
>>
>>
>> for id in np.nditer(npArray1):
>>newId=(np.where(npArray2==id))[0][0]

What are the dtypes of the arrays? And what are the typical sizes of
each of them. It can have a big effect on what makes a good solution
to the problem.

>> Is there anyway I can make the above faster? I need to run the script
>> above on much bigger arrays (50M). Please note that my two numpy arrays in
>> the lines above, npArray1 and npArray2  are not necessarily the same size,
>> but they are both 1d.
>
> You mean you are looking for the index of the first occurence in npArray2
> for every value of npArray1?
>
> I don't know how to do this in numpy (I'm not an expert), but even basic
> Python might be acceptable:

I'm not sure that numpy has any particular function that can be of use
here. Your approach below looks good though.

> lookup = {}
> for i, v in enumerate(npArray2):
> if v not in lookup:
> lookup[v] = i

Looking at this I wondered if there was a way to avoid the double hash
table lookup and realised it's the first time I've ever considered a
use for setdefault:

for i, v in enumerate(npArray2):
 lookup.setdefault(i, v)

Another option would be to use this same algorithm in Cython. Then you
can access the ndarray data pointer directly and loop over it in C.
This is the kind of scenario where that sort of thing can be well
worth doing.

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

Re: Simple exercise

[Mark Lawrence]

On 14/03/2016 15:06, Oscar Benjamin wrote:

On 14 March 2016 at 14:35, Rick Johnson  wrote:


I would strongly warn anyone against using the zip function
unless

...

I meant to say: absolutely, one hundred percent *SURE*, that
both sequences are of the same length, or, absolutely one
hundred percent *SURE*, that dropping values is not going to
matter. For that reason, i avoid the zip function like the
plague. I would much rather get an index error, than let an
error pass silently.


I also think it's unfortunate that zip silently discards items. Almost
always when I use zip I would prefer to see an error when the two
iterables are not of the same length. Of course you're not necessarily
safer with len and range:

a = [1, 2, 3]
b = 'abcde'

for n in range(len(a)):
 print(a[n], b[n])

--
Oscar



This is a job for Bi, no, 
https://docs.python.org/3/library/itertools.html#itertools.zip_longest


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

[justin walters]

How did you install python?
On Mar 14, 2016 1:30 AM, "Ezra Simms"  wrote:

> I cannot seem to get pymongo to find my python installation – keep getting
> an error saying pythin has not been found in the registry? Why is this.
>
> Sent from Mail for Windows 10
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Simple exercise

[Rick Johnson]

On Monday, March 14, 2016 at 9:19:04 AM UTC-5, alister wrote:
> A code smell does not necessarily mean the code is wrong,
> just that it warrants investigation as there is a strong
> possibility it may be sub- optimal

Yes, technically speaking, you're correct. 

But the concept of "code smell" has become something of a
scarlet letter within the programming community. Once you
apply it to someone's code, the stigma becomes very
difficult to rub off -- and not just the "external" stigma
you feel radiating from scornful stares of your peers, but
the "self-imposed" stigma as well. It has become a
derogatory term, and sadly, one that is thrown around much
too carelessly.

Sure, there are legitimate instances where the term should
be applied, but in the case of "zip vs explicit sequence
indexing", the usage of this term could influence a "less
experienced Python programmer", to adopt a very dangerous
habit *SIMPLY* because he does not want to be labeled a "bad
programmer". But the irony is, he may produce worse code by
blindly reaching for his "sequence zipper"!

The zip function is not something you should get in the
habit of using without first considering the consequences of
*EACH SPECIFIC USE-CASE*. Yes, it can be helpful at times,
and yes, it can make code easier to read. But it can also
create subtle bugs. Personally, i choose to avoid it, but
others should make the decision for themselves.

In a nutshell, the zip function is both "elegantly powerful"
and "cunningly destructive". So buyer beware. Because,
Python.org ain't no Walmart folks, and they sure as hell
don't give refunds for sequence members that evaporated into
the ether, after you adopted the bad habit of using zip,
simply because -> "Mark said so"!


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

Re: Missing something about timezones

[Ian Kelly]

On Mon, Mar 14, 2016 at 9:19 AM, Skip Montanaro
 wrote:
> Is this correct (today, with Daylight Savings in effect)?
>
 import pytz
 i.timezone
> 'America/Chicago'
 pytz.timezone(i.timezone)
> 
 ot
> datetime.datetime(2016, 3, 14, 9, 30, tzinfo= 'America/New_York' EDT-1 day, 20:00:00 DST>)
 ot.tzinfo
> 
>
> Shouldn't the America/Chicago timezone reflect DST?

Why should it? You only asked pytz for the Chicago timezone. You
didn't ask for it relative to any specific time.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: programeren met python

[Mark Lawrence]

On 13/03/2016 14:25, Irmen de Jong wrote:

On 12-3-2016 17:58, Imre De Craemer wrote:

  hoe moet je python dounlauden



Dit is een Engelse newsgroup, dus je kunt je vragen beter in het Engels stellen 
in
plaats van in het Nederlands. Maar om je vraag te beantwoorden:
Ga naar https://www.python.org/downloads/ met je web browser en klik dan op de 
gele knop
"download python 3.5.1". Dan downloadt hij de setup die je vervolgens moet 
starten.
Je vindt dan na afloop in je start menu Python 3.5 en ook Idle (Python 3.5) 
terug
waarmee je aan de slag kunt.
Als je nog meer informatie nodig hebt om aan de slag te gaan, kun je hier 
bijvoorbeeld
kijken: https://wiki.python.org/moin/BeginnersGuide
of hier misschien: http://cscircles.cemc.uwaterloo.ca/nl/  (dat is in het 
Nederlands)
Of stel je vragen gewoon hier natuurlijk (in het Engels).

Veel succes!
Irmen de Jong


[English:]
This is an English newsgroup, so it's better to ask your questions in English 
rather
than in Dutch. But to answer your question:
Visit https://www.python.org/downloads/ with your web browser and click the 
yellow
button "download Python 3.5.1". It will then download the setup that you'll 
have to
start afterwards. You'll then find in your start menu Python 3.5 and also Idle 
(Python
3.5) with which you can get going.
If you need more information to get started, you can perhaps look at this:
https://wiki.python.org/moin/BeginnersGuide
or maybe this: http://cscircles.cemc.uwaterloo.ca/nl/   (which is in Dutch)
You can always ask your questions here of course (in English).


Good luck!

Irmen de Jong



Such a wonderful response has made my day :)

--
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: Missing something about timezones

[Skip Montanaro]

On Mon, Mar 14, 2016 at 10:26 AM, Ian Kelly  wrote:
> Why should it? You only asked pytz for the Chicago timezone. You
> didn't ask for it relative to any specific time.

Thanks. I thought using America/Chicago was supposed to automagically
take into account transitions into and out of Daylight Savings. Is
there some way to get that?

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

Re: Descriptors vs Property

[Mark Lawrence]

On 13/03/2016 13:20, Veek. M wrote:

Thomas 'PointedEars' Lahn wrote:


   Nobility lies in action, not in name.
 —Surak


Someone called Ned.B who i know elsewhere spoke on your behalf. I'm glad
to say I like/trust Ned a bit so *huggles* to you, and I shall snip.

Also, sorry about the 'Steve' thing - bit shady dragging in crap from
elsewhere but my reputation here is not sterling (too many Q not many
A), so I tend to defend it willy-nilly. Sorry for the excess BP I may
have caused as well. One more *huggles* to you.

All the huggling doesn't imply i trust you etc etc. Ah umm.. anyway :p
ciao till my next Q



Please ignore 'PointedEars', every month or so for some weird reason he 
complains about people not using their real names.  Why?  I've no idea, 
but I suggest that you don't ask him or we'll be here until Doomsday.


--
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: Simple exercise

[MRAB]

On 2016-03-14 15:22, Rick Johnson wrote:

On Monday, March 14, 2016 at 9:19:04 AM UTC-5, alister wrote:

A code smell does not necessarily mean the code is wrong,
just that it warrants investigation as there is a strong
possibility it may be sub- optimal


Yes, technically speaking, you're correct.

But the concept of "code smell" has become something of a
scarlet letter within the programming community. Once you
apply it to someone's code, the stigma becomes very
difficult to rub off -- and not just the "external" stigma
you feel radiating from scornful stares of your peers, but
the "self-imposed" stigma as well. It has become a
derogatory term, and sadly, one that is thrown around much
too carelessly.

Sure, there are legitimate instances where the term should
be applied, but in the case of "zip vs explicit sequence
indexing", the usage of this term could influence a "less
experienced Python programmer", to adopt a very dangerous
habit *SIMPLY* because he does not want to be labeled a "bad
programmer". But the irony is, he may produce worse code by
blindly reaching for his "sequence zipper"!

The zip function is not something you should get in the
habit of using without first considering the consequences of
*EACH SPECIFIC USE-CASE*. Yes, it can be helpful at times,
and yes, it can make code easier to read. But it can also
create subtle bugs. Personally, i choose to avoid it, but
others should make the decision for themselves.

In a nutshell, the zip function is both "elegantly powerful"
and "cunningly destructive". So buyer beware. Because,
Python.org ain't no Walmart folks, and they sure as hell
don't give refunds for sequence members that evaporated into
the ether, after you adopted the bad habit of using zip,
simply because -> "Mark said so"!

In other words, code is like cheese. Some of it smells, even when 
there's nothing wrong. :-)


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

Re: Simple exercise

[Peter Otten]

Ian Kelly wrote:

> On Mon, Mar 14, 2016 at 9:06 AM, Oscar Benjamin
>  wrote:
>> On 14 March 2016 at 14:35, Rick Johnson 
>> wrote:
>>>
>>> I would strongly warn anyone against using the zip function
>>> unless
>> ...
>>> I meant to say: absolutely, one hundred percent *SURE*, that
>>> both sequences are of the same length, or, absolutely one
>>> hundred percent *SURE*, that dropping values is not going to
>>> matter. For that reason, i avoid the zip function like the
>>> plague. I would much rather get an index error, than let an
>>> error pass silently.
>>
>> I also think it's unfortunate that zip silently discards items. Almost
>> always when I use zip I would prefer to see an error when the two
>> iterables are not of the same length.
> 
> It's sometimes very useful, though. For example on multiple occasions
> I've taken advantage of the fact that enumerate(x) is equivalent to
> zip(itertools.count(), x). If zip raised an error then that would only
> be possible using islice, and then only if the length is known in
> advance.
> 
> Also, in order for zip to know that the lengths are not equal, it
> would have to try to read one additional item from the longer
> iterable. That's rather unfortunate if it's an iterator and you're
> hoping to catch the exception and then use the rest of the iterator
> for something else.

That's a problem you may run into with the current zip(), too -- unless you 
know that the first is the shortest iterator:

>>> from itertools import count
>>> indices = count()
>>> for items in "abc", "def", "gh":
...list(zip(indices, items))
... 
[(0, 'a'), (1, 'b'), (2, 'c')]
[(4, 'd'), (5, 'e'), (6, 'f')]
[(8, 'g'), (9, 'h')]

I'm with Oscar here, raising an exception would be the better default; the 
current implementation could have been made available as 
itertools.zip_shortest().

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

Re: Simple exercise

[Rick Johnson]

On Monday, March 14, 2016 at 10:06:56 AM UTC-5, Oscar Benjamin wrote:
> On 14 March 2016 at 14:35, Rick Johnson  wrote:
> >
> > I would strongly warn anyone against using the zip function
> > unless
> ...
> > I meant to say: absolutely, one hundred percent *SURE*, that
> > both sequences are of the same length, or, absolutely one
> > hundred percent *SURE*, that dropping values is not going to
> > matter. For that reason, i avoid the zip function like the
> > plague. I would much rather get an index error, than let an
> > error pass silently.
> 
> I also think it's unfortunate that zip silently discards items. Almost
> always when I use zip I would prefer to see an error when the two
> iterables are not of the same length. 

Yes. zip is no doubt more Pythonic than any indexing will
ever be, but without a way to manage this "discarding
issue", i can't justify using the function. There are three
possible ways to solve this dilemma:

  (1) Add a keyword argument to zip, something like
  "validateLengths" -- which will default to False. 
  
  (2) Create a new zip function called "strictzip" which
  will always throw and error when all of the sequences
  don't share the same length. 
  
  (3) Encourage every programmer to write their own wrapper
  around zip.

And since we've recently learned that Python programmers
have an aversion to typing, number three is out the
question.

> Of course you're not necessarily safer with len and range:
> 
> a = [1, 2, 3]
> b = 'abcde'
> 
> for n in range(len(a)):
> print(a[n], b[n])

You make a valid point here. So i'm not 100% protected using
indexing, however, i am 100% unprotected using zip. Whew...
I'm still right, but *ONLY* because i'm not 100% wrong.

PS: For second there, i was afraid my impeccable reputation
might have been in jeopardy. O:-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Simple exercise

[Rick Johnson]

On Monday, March 14, 2016 at 10:17:54 AM UTC-5, Ian wrote:
> It's sometimes very useful [for zip to discard values],
> though. 

The obvious solution is to allow the caller to decide if the
error should be raised, or not. Currently, the caller has no
control over the internals of zip unless he creates a
wrapper, or validates the sequences by hand, before passing 
them into zip. Both of which are violating DRY.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Missing something about timezones

[Ian Kelly]

On Mon, Mar 14, 2016 at 9:32 AM, Skip Montanaro
 wrote:
> On Mon, Mar 14, 2016 at 10:26 AM, Ian Kelly  wrote:
>> Why should it? You only asked pytz for the Chicago timezone. You
>> didn't ask for it relative to any specific time.
>
> Thanks. I thought using America/Chicago was supposed to automagically
> take into account transitions into and out of Daylight Savings. Is
> there some way to get that?

Use the timezone to localize a specific time, and then if it's
specifically the timezone that you're interested in, you can get it
from the datetime.

>>> from datetime import datetime
>>> import pytz
>>> tz = pytz.timezone('America/Chicago')
>>> tz

>>> dt = datetime.now()
>>> dt
datetime.datetime(2016, 3, 14, 10, 16, 40, 404608)
>>> loc_dt = tz.localize(dt)
>>> loc_dt
datetime.datetime(2016, 3, 14, 10, 16, 40, 404608, tzinfo=)

Note that the above example is technically incorrect since
datetime.now() returns local time and I'm not in the Chicago timezone,
but it demonstrates the process.

Also, if you haven't already read the pytz documentation, you should.
http://pythonhosted.org/pytz/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Mark Lawrence]

On 14/03/2016 14:43, BartC wrote:

On 13/03/2016 09:39, Steven D'Aprano wrote:

On Sun, 13 Mar 2016 04:54 am, BartC wrote:



Common sense tells you it is unlikely.


Perhaps your common sense is different from other people's common
sense. To
me, and many other Python programmers, it's common sense that being
able to
replace functions or methods on the fly is a useful feature worth having.
More on this below.

Perhaps this is an example of the "Blub Paradox":


Perhaps it's time to talk about something which many languages have, but
Python hasn't. Not as far as I know anyway.

That's references to names (sometimes called pointers). So if I write:

  a = 100
  f(a)

then function f gets passed the value that a refers to, or 100 in this
case. But how do you pass 'a' itself?

Perhaps you can say:

   f('a')

and f can do some sort of lookup, if it knows the caller's context, for
such a name and retrieve the value that way. But that's rather
heavy-handed, and f can't distinguish between a reference to a name, and
a string.


http://jeffknupp.com/blog/2012/11/13/is-python-callbyvalue-or-callbyreference-neither/

--
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: Missing something about timezones

[Skip Montanaro]

On Mon, Mar 14, 2016 at 11:20 AM, Ian Kelly  wrote:
> Note that the above example is technically incorrect since
> datetime.now() returns local time and I'm not in the Chicago timezone,
> but it demonstrates the process.
>
> Also, if you haven't already read the pytz documentation, you should.
> http://pythonhosted.org/pytz/

Thanks. I have remained pretty naive about timezones (sorry for the
pun). The platform I use actually does the right thing, but like a
dope I failed to use the mechanisms it provided.

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

Re: Missing something about timezones

[Carl Meyer]

Hi Skip,

On 03/14/2016 09:32 AM, Skip Montanaro wrote:
> On Mon, Mar 14, 2016 at 10:26 AM, Ian Kelly  wrote:
>> Why should it? You only asked pytz for the Chicago timezone. You
>> didn't ask for it relative to any specific time.
> 
> Thanks. I thought using America/Chicago was supposed to automagically
> take into account transitions into and out of Daylight Savings. Is
> there some way to get that?

Yes, pytz can handle DST correctly automatically when you give it
'America/Chicago', but until you apply that timezone to a particular
datetime, there is no DST to handle. There is no implicit assumption of
"today" when you do `pytz.timezone('America/Chicago').

If you apply the timezone to a particular datetime, you'll see that it
does reflect DST correctly:

>>> import datetime, pytz
>>> tz = pytz.timezone('America/Chicago')
>>> tz

>>> import datetime
>>> dt = datetime.datetime.now()
>>> dtl = tz.localize(dt)
>>> dtl
datetime.datetime(2016, 3, 14, 10, 11, 13, 514375, tzinfo=)

Carl



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

Embedding Python into C set up issues

[steven . flolid]

Good morning!

I have been working with Python for the last few months. I have created a 
script that I want to embed into a C++ environment, specifically CDT for 
eclipse. I have read the https://docs.python.org/2/extending/index.html and 
understand the ideas and differences between the two languages. 

However, I am having great trouble getting Py_Initialize() to work in the both 
CDT and Visual Studio 2015. I have as a starting point a simple C program that 
prints hello world then calls py_initialize and then prints another line of 
text to the screen. Calling Py_initialize causes the script to exit with exit 
code 1. I am at a loss as to why this is happening. I have read the 
documentation about Py_Initialize() calling exit when it should raise an error 
so I understand it may be difficult to debug this issue.

Here are the details for my system:

Windows 7 64bit running python 2.7.11 using Visual Studio Community Edition 
2015. 

Python is installed in the default folder of C:\Python27 and is the only copy 
of python installed.

Path is has C:\Python27 and C:\Python27\DLLs appended to it in that order.

PYTHONPATH is set to C:\python27lib

In visual studio:

C++/Additional Include Directories has C:\Python27\include appended to it

Linker/Additional Library Directories has C:\Python27\libs appended to it

Linker/Additional Dependencies has python27.lib appended to it



Here is the source code:

#include 
#include 

int main() {
printf("hello world");
Py_Initialize();
printf("hello world please");
}

I feel like I must be missing something, I just don't know what it is. Any 
documentation or help would be much appreciated.

Sincerely,

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

Re: Interaction between pygame and python

[Rick Johnson]

On Monday, March 14, 2016 at 3:28:40 AM UTC-5, Tyson wrote:
> I am having a lot of trouble getting python to find the
> pygame module; my operating system is Windows 7.  Can you
> offer any help?  . Should I download pygame into the same
> folder as Python? . any ideas at all?

If you're new to Python, or even programming in general, i
would highly suggest that you download a pygame executable
installer, and not source code. 

Typically, the you'll want third party libraries, and that's
what pygame *IS*, a third party library, to be installed into
your "PythonXY/Lib/site-packagages" folder. 

If you download and run an installer, one that is
appropriate for your operating system and Python version,
everything will be taken care of for you.

Since you are using Python 3.5.1 on a windows box, you'll
want to download and install the executable named
"pygame-1.9.1-py3.1.msi". You can get it here:

  http://www.pygame.org/download.shtml

Also, have a look at this page for some helpful "getting
started" info:

  http://www.pygame.org/wiki/GettingStarted

After you run the installer, open up a fresh Python shell,
and try to import pygame again. If that import fails, come
back here and post the full traceback.

> Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:38:48)
> [MSC v.1900 32 bit (Intel)] on win32
> 
> >>> import pygame
> 
> Traceback (most recent call last):
> 
>   File "", line 1, in 
> 
>import pygame
> 
> ImportError: No module named 'pygame'
> 
> >>> import pygame, sys

Just FYI: importing the "sys" module won't help. If pygame
is not there, it's not there -- plain and simple. 

Now, it could be that you *DO* have pygame installed. but
Python cannot find it. But the best thing for you to do at
this time, is to uninstall any current versions of pygame,
and/or delete any files belonging to pygame from your
computer, and start fresh by running the installer.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Loading error message

[Arie van Wingerden]

Hi Oscar,

no. By default W10 appears to have them NOT installed (at least that is
what I experienced).
You really need the SDK to be installed.
Also the path must point to the libs installed by the SDK.
Now it works without all those warnings.

Thx,
   Arie

2016-03-14 15:59 GMT+01:00 Oscar Benjamin :

> On 14 March 2016 at 12:07, Arie van Wingerden  wrote:
> > that is weird. I am using Windows 10 and get exactly the same "warnings"
> > when I run PyInstaller.
> > But the update you mention is only available for up to Windows 8.1.
> >
> > What about Windows 10 then??
>
> I'm not sure what you mean. Windows 10 should already have the UCRT so
> it shouldn't need the update. Is it possibly a bug in pyinstaller?
> What exactly are you doing to see this error message?
>
> --
> Oscar
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Loading error message

[Oscar Benjamin]

I've fixed the quoting below. Can you not top-post please Arie?

On 14 March 2016 at 16:59, Arie van Wingerden  wrote:
> 2016-03-14 15:59 GMT+01:00 Oscar Benjamin :
>>
>> On 14 March 2016 at 12:07, Arie van Wingerden  wrote:
>> > that is weird. I am using Windows 10 and get exactly the same "warnings"
>> > when I run PyInstaller.
>> > But the update you mention is only available for up to Windows 8.1.
>> >
>> > What about Windows 10 then??
>>
>> I'm not sure what you mean. Windows 10 should already have the UCRT so
>> it shouldn't need the update. Is it possibly a bug in pyinstaller?
>> What exactly are you doing to see this error message?
> Hi Oscar,
>
> no. By default W10 appears to have them NOT installed (at least that is what
> I experienced).
> You really need the SDK to be installed.
> Also the path must point to the libs installed by the SDK.
> Now it works without all those warnings.

What works? Python or pyinstaller or what? If pyinstaller do you see
the error when creating an executable or when running it?

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

Re[2]: Loading error message

[Arie van Wingerden]

maandag, 14 maart 2016, 06:04PM +0100 van Oscar Benjamin 
:
>I've fixed the quoting below. Can you not top-post please Arie?
>On 14 March 2016 at 16:59, Arie van Wingerden < xapw...@gmail.com > wrote:
>> 2016-03-14 15:59 GMT+01:00 Oscar Benjamin < oscar.j.benja...@gmail.com >:
>>>
>>> On 14 March 2016 at 12:07, Arie van Wingerden < xapw...@gmail.com > wrote:
>>> > that is weird. I am using Windows 10 and get exactly the same "warnings"
>>> > when I run PyInstaller.
>>> > But the update you mention is only available for up to Windows 8.1.
>>> >
>>> > What about Windows 10 then??
>>>
>>> I'm not sure what you mean. Windows 10 should already have the UCRT so
>>> it shouldn't need the update. Is it possibly a bug in pyinstaller?
>>> What exactly are you doing to see this error message?
>> Hi Oscar,
>>
>> no. By default W10 appears to have them NOT installed (at least that is what
>> I experienced).
>> You really need the SDK to be installed.
>> Also the path must point to the libs installed by the SDK.
>> Now it works without all those warnings.
>What works? Python or pyinstaller or what? If pyinstaller do you see
>the error when creating an executable or when running it?
>--
>Oscar
Sorry about top posting.
Creating standalone exe with pyinstaller gave all the warnings about missing 
libs.
That is solved by inst w10 sdk + add sdk dir to path var.
/arie
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Mark Lawrence]

On 13/03/2016 20:12, Marko Rauhamaa wrote:

BartC :


Exactly why having ready-made solutions is preferable to everyone
hacking their own solutions to switch.


A developer friend of mine once said insightfully that the point of OO
is getting rid of switch statements. IOW, most use cases for switch
statements are handled with virtual functions.

The most significant exception in my experience is message decoding,
where switches/ifs cannot be avoided.


Marko



http://c2.com/cgi/wiki?SwitchStatementsSmell

--
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: Descriptors vs Property

[Rustom Mody]

On Monday, March 14, 2016 at 9:06:01 PM UTC+5:30, Mark Lawrence wrote:
> On 13/03/2016 13:20, Veek. M wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >
> Nobility lies in action, not in name.
>   --Surak
> >
> > Someone called Ned.B who i know elsewhere spoke on your behalf. I'm glad
> > to say I like/trust Ned a bit so *huggles* to you, and I shall snip.
> >
> > Also, sorry about the 'Steve' thing - bit shady dragging in crap from
> > elsewhere but my reputation here is not sterling (too many Q not many
> > A), so I tend to defend it willy-nilly. Sorry for the excess BP I may
> > have caused as well. One more *huggles* to you.
> >
> > All the huggling doesn't imply i trust you etc etc. Ah umm.. anyway :p
> > ciao till my next Q
> >
> 
> Please ignore 'PointedEars', every month or so for some weird reason he 
> complains about people not using their real names.  Why?  I've no idea, 
> but I suggest that you don't ask him or we'll be here until Doomsday.

Anyhow what's a 'real name'??
Why is the name my friends call me by more/less real than the one my parents
call me?   And even parents keep changing their preferences -- nicknames etc!

Yeah there is a name on my passport stamped by some government (so-called)... 
What of it?

If we apply Thomas' own aphorism -- Nobility lies in action, not in name --
hardly any government would pass.

What of people who dont have passports/bank accounts etc?
http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

Not to mention that when a genuine malign-intent change of name is effected
it is certain to 'pass' the real name test

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

Re: Re[2]: Loading error message

[Oscar Benjamin]

On 14 March 2016 at 17:15, Arie van Wingerden  wrote:
> I've fixed the quoting below. Can you not top-post please Arie?
> On 14 March 2016 at 16:59, Arie van Wingerden < xapw...@gmail.com > wrote:
>> 2016-03-14 15:59 GMT+01:00 Oscar Benjamin < oscar.j.benja...@gmail.com >:
>>>
>>> On 14 March 2016 at 12:07, Arie van Wingerden < xapw...@gmail.com >
>>> wrote:
>>> > that is weird. I am using Windows 10 and get exactly the same
>>> > "warnings"
>>> > when I run PyInstaller.
>>> > But the update you mention is only available for up to Windows 8.1.
>>> >
>>> > What about Windows 10 then??
>>>
>>> I'm not sure what you mean. Windows 10 should already have the UCRT so
>>> it shouldn't need the update. Is it possibly a bug in pyinstaller?
>>> What exactly are you doing to see this error message?
>> Hi Oscar,
>>
>> no. By default W10 appears to have them NOT installed (at least that is
>> what
>> I experienced).
>> You really need the SDK to be installed.
>> Also the path must point to the libs installed by the SDK.
>> Now it works without all those warnings.
> What works? Python or pyinstaller or what? If pyinstaller do you see
> the error when creating an executable or when running it?
> --
> Oscar
>
> Creating standalone exe with pyinstaller gave all the warnings about missing
> libs.

Okay well then that's a separate issue. The OP was unable to run
Python because these libs were missing. You are trying to compile C
code using pyinstaller which means that you need these libs available
on PATH I guess.

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

Re[3]: Re[2]: Loading error message

[Arie van Wingerden]

maandag, 14 maart 2016, 06:21PM +0100 van Oscar Benjamin 
:
>On 14 March 2016 at 17:15, Arie van Wingerden < xapw...@gmail.com > wrote:
>> I've fixed the quoting below. Can you not top-post please Arie?
>> On 14 March 2016 at 16:59, Arie van Wingerden <  xapw...@gmail.com > wrote:
>>> 2016-03-14 15:59 GMT+01:00 Oscar Benjamin <  oscar.j.benja...@gmail.com >:

 On 14 March 2016 at 12:07, Arie van Wingerden <  xapw...@gmail.com >
 wrote:
 > that is weird. I am using Windows 10 and get exactly the same
 > "warnings"
 > when I run PyInstaller.
 > But the update you mention is only available for up to Windows 8.1.
 >
 > What about Windows 10 then??

 I'm not sure what you mean. Windows 10 should already have the UCRT so
 it shouldn't need the update. Is it possibly a bug in pyinstaller?
 What exactly are you doing to see this error message?
>>> Hi Oscar,
>>>
>>> no. By default W10 appears to have them NOT installed (at least that is
>>> what
>>> I experienced).
>>> You really need the SDK to be installed.
>>> Also the path must point to the libs installed by the SDK.
>>> Now it works without all those warnings.
>> What works? Python or pyinstaller or what? If pyinstaller do you see
>> the error when creating an executable or when running it?
>> --
>> Oscar
>>
>> Creating standalone exe with pyinstaller gave all the warnings about missing
>> libs.
>Okay well then that's a separate issue. The OP was unable to run
>Python because these libs were missing. You are trying to compile C
>code using pyinstaller which means that you need these libs available
>on PATH I guess.
>--
>Oscar
Yes, that's right!
/arie
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation in Python

[Rick Johnson]

On Sunday, March 13, 2016 at 5:11:50 AM UTC-5, Steven D'Aprano wrote:
> On Sun, 13 Mar 2016 03:44 am, Ian Kelly wrote:
> 
> > On Fri, Mar 11, 2016 at 7:39 PM, Rick Johnson
> >  wrote:
> >> At run-time, i don't care how large a "module namespace" may be.
> >> Sometimes a module namespace will be small, with only a few
> >> exposed symbols, but sometimes, a module namespace will expose
> >> thousands of symbols.
> > 
> > Thousands, really? What system do you use to ensure that symbols
> > don't accidentally collide with one another? Because, you know,
> > Python won't check this for you even within a single file, unlike
> > say C++ which does allow splitting namespaces across multiple
> > files. A linter might, but not at runtime, and I don't expect it
> > will be smart enough to notice if the definitions are in different
> > files.
> 
> I would hate to use an API with "thousands" of symbols in a single
> namespace. I find `os` difficult enough, and it has less than a
> quarter thousand:
> 
> The decimal module is, in my opinion, about as big as a module
> should ever get before it becomes too unwieldy to maintain, and it
> has less than a hundred symbols:
> 
> While it is true that the Zen says "Flat is better than nested", it
> does also say Namespaces are one honking great idea -- let's do more
> of those! so at the point that your namespace has more symbols than
> can be managed by the merely mortal, then it's well past time to
> split some of them off into separate namespaces.

But exactly where, and exactly how to drawn those lines, is
not always obvious. Splitting a large module, of similar
functionality, into smaller modules, can make the interface
confusing. Consider the following "large sized modules".

# BEGIN INTERACTIVE SESSION
PY> import OpenGL.GL
PY> import OpenGL.GLU
PY> import OpenGL.GLX
PY> import OpenGL.GLUT
PY> import OpenGL.GLE
PY> len(dir(OpenGL.GL))
3656
PY> len(dir(OpenGL.GLU))
250
PY> len(dir(OpenGL.GLX))
390
PY> len(dir(OpenGL.GLUT))
394
PY> len(dir(OpenGL.GLE))
64
PY> import Tkinter as tk
PY> len(dir(tk))
199
PY> root = tk.Tk()
PY> f = tk.Frame(root)
PY> len(dir(f))
200
# END INTERACTIVE SESSION

Ignoring Tkinter, which is a gawd awful mess, how would you
re-organize the 3,656 symbols in OpenGL.GL into smaller
modules, without dividing them up along some random or 
arbitrary lines? 

> [...]
> >> But option two is no better, because once we cut and paste
> >> portions of the code into satellite files, we lose the ability to
> >> "easily share state". Then we're forced to start "hacking at the
> >> weeds" with import contortions and monkey patches, all the while,
> >> fearing the dreaded circular import. NO, THIS IS INSANITY! WHAT
> >> WE NEED IS AN OPTION 3!
> 
> What we actually need is a way to have less shared state. If you
> have so much shared state that you cannot manage it in a single
> module, you have a problem no matter what you do.

You're missing my point. I can manage the *STATE* just fine
in a single module, actually, managing *STATE* in the same
module is very easy, regardless of how many lines are in
the file. No, it is not state that becomes unwieldy, it is
*EDITING* that becomes unwieldy. I break large source files
into small source files, simply so i don't go insane when
trying to edit them.


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

Re: Interaction between pygame and python

[Terry Reedy]

On 3/14/2016 12:53 PM, Rick Johnson wrote:


Since you are using Python 3.5.1 on a windows box, you'll
want to download and install the executable named
"pygame-1.9.1-py3.1.msi". You can get it here:

   http://www.pygame.org/download.shtml


Or get pygame-1.9.2a0-cp35-none-win32.whl from
http://www.lfd.uci.edu/~gohlke/pythonlibs/

Instructions on installing with pip are at the top of the page.

--
Terry Jan Reedy

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 14/03/2016 17:17, Mark Lawrence wrote:

On 13/03/2016 20:12, Marko Rauhamaa wrote:

BartC :


Exactly why having ready-made solutions is preferable to everyone
hacking their own solutions to switch.


A developer friend of mine once said insightfully that the point of OO
is getting rid of switch statements. IOW, most use cases for switch
statements are handled with virtual functions.

The most significant exception in my experience is message decoding,
where switches/ifs cannot be avoided.



http://c2.com/cgi/wiki?SwitchStatementsSmell


I get it. The author doesn't like switch statements!

But they can be a succinct and convenient way of expressing some code 
patterns. Nobody is obliged to use them, but it would nice for a 
language to give the /choice/. And since they mainly involve syntax, the 
cost of providing them is small.


Here's one pattern:

switch X
when A,B   then S1
when C then S2
when D,E,F then S3
elseS4
end switch

The typical characteristics - when A to F are known at compile-time - are:

* X is only evaluated once
* None of A to F need to be evaluated
* Only a single test is needed, no matter how many case expressions
* Only one of S1 to S4 is executed (at most one when there is no else)

(When A to F are not known at compile time, then it might be implemented 
differently. X is still evaluated once, but A to F are evaluated and 
tested in sequence until a match or not is found. However, nothing need 
change in the source.)


Here's another pattern, which can also be implemented with an underlying 
switch:


 X = (N |A, B, C, ... |Z)

This selects the N'th value from A, B, C (in Python, probably 0-based). 
Z is the default if N is out of range. A, B, C can be any expressions.


The main characteristic is that only *one* of A, B, C  or Z evaluated, 
which is the difference between just using a list.


Really, it becomes difficult to see what people have against switch. 
(Unless perhaps their favourite language doesn't have it and they're 
trying to justify that.)


> http://c2.com/cgi/wiki?SwitchStatementsSmell

(Code-smell to me means code dominated by loads of classes, especially 
for no good reason. But I'm not suggesting a language shouldn't have them.)


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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Michael Torrie]

On 03/14/2016 08:43 AM, BartC wrote:
> But how do you pass 'a' itself?
> 
> Perhaps you can say:
> 
>f('a')
> 
> and f can do some sort of lookup, if it knows the caller's context, for 
> such a name and retrieve the value that way. But that's rather 
> heavy-handed, and f can't distinguish between a reference to a name, and 
> a string.
> 
> Unless maybe you wrap this up in a class and  Well, you end up with 
> something that might emulate a name reference, but with so much 
> complexity and such overheads that it is not worthwhile.

Maybe, but I don't think so.  Is there really overhead in passing a
mutable object (a list) and working on it vs passing pieces of a list
one at a time? The lookup is the same, or maybe less.  In your example,
you have to do lookups for each item going into the function, and then
again when you assign the new values back into place in your source
list.  Passing the whole list into the function would seem to be faster.

> Yet, this is a feature I use extensively, far more often than I would 
> use mutable functions. And in fact it was used in the code for my jpeg 
> example, where in the Python I has to use a workaround (see below).

I think this is all just a matter of perspective. You seem convinced
that the C way is the only way to go from a performance standpoint. This
may or may not be true. There are certainly other paradigms. For example
functional programming disallows side-effects altogether. This allows
effortless chaining of functions, something you cannot do with your
function (subroutine really) that modifies things in place.  Maybe you
need to reexamine what your basic data structures are and need to be.
If you need a block of mutable values to do your processing on, perhaps
that should be encapsulated into its own set of routines.

Sounds like this is a case where you could alter your method to better
fit Python's strengths, rather than work around it's differences or
weaknesses compared to a language like C.

But it could be that Python is ill-suited to this kind of bit-twiddling
and that C is the proper place to do it (Chris has argued for this from
the beginning).


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

Re: Encapsulation in Python

[sohcahtoa82]

On Friday, March 11, 2016 at 6:39:53 PM UTC-8, Rick Johnson wrote:
> On Friday, March 11, 2016 at 9:48:22 AM UTC-6, Ian wrote:
> > On Thu, Mar 10, 2016 at 5:45 PM, Rick Johnson
> > The honorable Rick Johnson wrote:
> > > Many times, i would have preferred to define my module space
> > > across multiple files, multiple files that could share state
> > > without resorting to the yoga-style "import contortions",
> > > and/or the dreaded "circular import nightmares" that plague
> > > our community today.
> >
> > Sounds to me like you're blaming Python for your own poor design.
> > Possible solutions:
> >
> > 1) Don't do that. If your module is too big for one file, then it's
> > likely poorly organized and doesn't all belong in one module anyway.
> 
> Apparently you've missed the many heated arguments between
> Chris Angelico and myself concerning the size of source
> files. I have *ALWAYS* taken the position that source files
> should be kept as small as possible, but that position is
> more relevant in Python, were modules are defined by a
> single source file. I don't take the Java position that a
> module can only contain one class, but i like to keep the
> number of classes (IN MY SOURCE FILES) small.
> 
> At run-time, i don't care how large a "module namespace" may
> be. Sometimes a module namespace will be small, with only a
> few exposed symbols, but sometimes, a module namespace will
> expose thousands of symbols. The size of a "run-time module"
> is irrelevant in most languages, but here in Python, were
> module namespace is defined by the contents of *ONE SINGLE
> SOURCE FILE*, the whole ballgame is changed. If i need to
> create a module that contains many exposed symbols in
> Python, i'm forced to do one of the following:
> 
>   (1) Write all my code in a single *GIGANTIC* file...
> 
> or
> 
>   (2) Create one file that will be the "mother-ship module",
>   and N files that will be the "satellite modules", and from
>   inside the mother-ship, import all the symbols from all
>   the satellites. Ha, but in reality, it's not that simple,
>   because state does not "magically" travel between modules!
> 
> ##
> # foo.py #
> ##
> FOO_SHARED_STATE = "foo"
> import _fooSatilite1
> _fooSatilite1.FOO_SHARED_STATE = FOO_SHARED_STATE
> from _fooSatilite1 import *
> import _fooSatilite2
> _fooSatilite2.FOO_SHARED_STATE = FOO_SHARED_STATE
> from _fooSatilite2 import *
> print 'This is the mother-ship called foo'
> ...
> 
> 
> # _fooSatilite1.py #
> 
> from _fooConstants import *
> print 'This is foo-fighter1, reporting for duty'
> print FOO_SHARED_STATE
> ...
> 
> 
> # _fooSatilite2.py #
> 
> from _fooConstants import *
> print 'This is foo-fighter2, reporting for duty'
> print FOO_SHARED_STATE
> ...
> 
> But i find both to be absurd. Writing all code in a single
> file might be fine for a toy module that contains a handful
> of functions or classes or vars, but once we start creating 
> anything in the "professional size range", it will become 
> an "editing nightmare" of epic proportions!
> 
> But option two is no better, because once we cut and paste
> portions of the code into satellite files, we lose the
> ability to "easily share state". Then we're forced to start
> "hacking at the weeds" with import contortions and monkey
> patches, all the while, fearing the dreaded circular import.
> 
> 
> NO, THIS IS INSANITY!  WHAT WE NEED IS AN OPTION 3!
> 
>  (3) Allow a programmer to define module space at will
> 
> ##
> # foo.py #
> ##
> module foo
> FOO_SHARED_STATE = "foo"
> print 'This is the mother-ship called foo'
> ...
> 
> 
> # _fooSatilite1.py #
> 
> module foo
> print 'This is foo-fighter1, reporting for duty'
> print FOO_SHARED_STATE # NO MP REQUIRED!
> ...
> 
> 
> # _fooSatilite2.py #
> 
> module foo
> print 'This is foo-fighter2, reporting for duty'
> print FOO_SHARED_STATE # NO MP REQUIRED!
> ...
> 
> No need for import contortions, no need for monkey patching,
> but most importantly, no need for professional programmers
> to feel as though they are penchant little children, who
> need their "module diapers" wrapped for them by mommy
> Python, who, after popping one too many "mother's little
> helpers", has a nasty habit of wrapping our diapers too damn
> tight -- what a drag, it is, getting old...
> 
> > 2) Clearly define which module is to be imported first. Then follow
> > it. When module b is imported, it should import module a. When module
> > a is imported, it *shouldn't* import module b until it's defined all
> > of its own members first. If module a depends on anything from module
> > b at import time, then refactor so 

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Marko Rauhamaa]

BartC :

> (Code-smell to me means code dominated by loads of classes, especially
> for no good reason. But I'm not suggesting a language shouldn't have
> them.)

Ok, you don't like OO. Fine. Python is deep in OO.

"When in Rome, do as the Romans do."

Personally, I think OO is quite a cromulent paradigm.


Marko

PS Classes are not necessary for OO, but Python has taken that
traditional path.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Improving performance in matrix operations

[Oscar Benjamin]

On 9 March 2016 at 20:09, Drimades  wrote:
> I'm doing some tests with operations on numpy matrices in Python. As an 
> example, it takes about 3000 seconds to compute eigenvalues and eigenvectors 
> using scipy.linalg.eig(a) for a matrix 6000x6000. Is it an acceptable time?

I don't know really but you need to understand that numpy delegates
this kind of operation to the underlying BLAS library. It's possible
to have different BLAS libraries depending on how you installed numpy.
For example if you install numpy from
http://www.lfd.uci.edu/~gohlke/pythonlibs/
then you will have a numpy that is linked with the Intel MKL library
for BLAS which I think is that same as used in e.g. Matlab and many
other things. Alternatively if you installed from the numpy
sourceforge page then you'll have the ATLAS BLAS library. If you're
using e.g. Ubuntu and installed numpy from the Ubuntu repos it's
possible that you're using numpy's vendored unoptimised BLAS library.

Each of these different BLAS libraries has different characteristics
in terms of accuracy and speed so it's worth knowing which one you're
actually using.

> Any suggestions to improve? Does C++ perform better with matrices?

If you were working in C++ you would still want to link to a BLAS
library to do this so I don't see why it would make any difference
except that it would require you to work out how to compile and use
BLAS directly and then link to it from your C++ code.

> Another thing to consider is that matrices I'm processing are heavily sparse.

Then you should definitely use something that is targeted at sparse
matrices (as suggested by Fabien). This can give a massive boost in
performance.

> Do they implement any parallelism? While my code is running, one of my cores 
> is 100% busy, the other one 30% busy.

It sounds like the particular BLAS library you are using is not using
several cores for this workload. Different BLAS libraries have
different capabilities. Again you need to figure out which one you've
got and how it's compiled. It's possible that e.g. MKL has a parallel
eig function but that it is compiled with that behaviour disabled in
your setup.

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 14/03/2016 18:25, Marko Rauhamaa wrote:

BartC :


(Code-smell to me means code dominated by loads of classes, especially
for no good reason. But I'm not suggesting a language shouldn't have
them.)


Ok, you don't like OO. Fine. Python is deep in OO.

"When in Rome, do as the Romans do."

Personally, I think OO is quite a cromulent paradigm.


I've looked up cromulent but I'm still note sure whether you like OO or not!

(For myself, I've actually implemented some OO features, partly because 
you tend to end up there as a natural progression of language design.


But I use them sparingly. It's other people's use of it I object to...)

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

Re: Interaction between pygame and python

[Ian Kelly]

On Mon, Mar 14, 2016 at 10:53 AM, Rick Johnson
 wrote:
> If you download and run an installer, one that is
> appropriate for your operating system and Python version,
> everything will be taken care of for you.
>
> Since you are using Python 3.5.1 on a windows box, you'll
> want to download and install the executable named
> "pygame-1.9.1-py3.1.msi". You can get it here:
>
>   http://www.pygame.org/download.shtml

Unfortunately that installer is not appropriate for the OP's Python
version. The downloads on the pygame site are horrifically
out-of-date.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[alister]

On Mon, 14 Mar 2016 14:43:22 +, BartC wrote:

> On 13/03/2016 09:39, Steven D'Aprano wrote:
>> On Sun, 13 Mar 2016 04:54 am, BartC wrote:
> 
>>> Common sense tells you it is unlikely.
>>
>> Perhaps your common sense is different from other people's common
>> sense. To me, and many other Python programmers, it's common sense that
>> being able to replace functions or methods on the fly is a useful
>> feature worth having. More on this below.
>>
>> Perhaps this is an example of the "Blub Paradox":
> 
> Perhaps it's time to talk about something which many languages have, but
> Python hasn't. Not as far as I know anyway.
> 
> That's references to names (sometimes called pointers). So if I write:
> 
>   a = 100 f(a)
> 
> then function f gets passed the value that a refers to, or 100 in this
> case. But how do you pass 'a' itself?
Congratulations
you have just proven that you have faild in your understanimg of python @ 
stage 1 becuae you keep tying to us it a C

try the following

def test(x):
print (id(x)

a=100
print (id(a))
test(a)
a="Oops i was an idiot"
print (id(a))
test(a)

python always passes the object bound to a, not the value of a or a 
pointer to a
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 14/03/2016 19:45, alister wrote:

On Mon, 14 Mar 2016 14:43:22 +, BartC wrote:


On 13/03/2016 09:39, Steven D'Aprano wrote:

On Sun, 13 Mar 2016 04:54 am, BartC wrote:



Common sense tells you it is unlikely.


Perhaps your common sense is different from other people's common
sense. To me, and many other Python programmers, it's common sense that
being able to replace functions or methods on the fly is a useful
feature worth having. More on this below.

Perhaps this is an example of the "Blub Paradox":


Perhaps it's time to talk about something which many languages have, but
Python hasn't. Not as far as I know anyway.

That's references to names (sometimes called pointers). So if I write:

   a = 100 f(a)

then function f gets passed the value that a refers to, or 100 in this
case. But how do you pass 'a' itself?



Congratulations
you have just proven that you have faild in your understanimg of python @
stage 1 becuae you keep tying to us it a C

try the following

def test(x):
print (id(x)

a=100
print (id(a))
test(a)
a="Oops i was an idiot"
print (id(a))
test(a)

python always passes the object bound to a, not the value of a or a
pointer to a


Yes, and? I colloquially used 'value' instead of 'object', 'id' or 
'reference'. The latter would added confusion as I'm talking about a 
different kind of reference. And if you get rid of 'id' in your code, 
you will get values displayed.


But how do you pass something that refers to a itself?

There are good reasons for wanting to do so. Try writing this function 
in Python:


def swap(a,b):
b,a = a,b

x="one"
y="two"
swap(x,y)

print (x,y)

so that it displays "two" "one".

--
Bartc



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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Mark Lawrence]

On 14/03/2016 17:53, BartC wrote:

On 14/03/2016 17:17, Mark Lawrence wrote:

On 13/03/2016 20:12, Marko Rauhamaa wrote:

BartC :


Exactly why having ready-made solutions is preferable to everyone
hacking their own solutions to switch.


A developer friend of mine once said insightfully that the point of OO
is getting rid of switch statements. IOW, most use cases for switch
statements are handled with virtual functions.

The most significant exception in my experience is message decoding,
where switches/ifs cannot be avoided.



http://c2.com/cgi/wiki?SwitchStatementsSmell


I get it. The author doesn't like switch statements!



You clearly didn't bother reading the document.  I suggest you try 
again, and then attempt, just for once, to come back with some 
worthwhile comments.


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

Different sources of file

[Val Krem via Python-list]

Hi all,



I am made a little progress on using python.
I have five files to read from different sources  and concatenate them to one 
file.  From each file I want only to pick  few column  (x1, x2  and  x3). 
However, these columns say x3 was  a date in one file it was recorded as a 
character  (2015/12/26)  and in the other file it was records  (20151226)  and 
in the other file it was recorded as  (26122015). How do I standardized these 
into one form (mmdd-20151126). If there is no date then delete that record

2. The other variable x2. In one of the one files it was recorded as  "M" and 
"F". In the other  file  x3  is  1 for male and 2 for female.  So I want to 
change  all to 1 or 2. if this variable is out of range M / F or 1 or 2 then 
delete that record

3.  After doing all these I want combine all files into one  and send it to 
output. 

Finally, do some statistics  such as number of records read from each file. 
Distribution of sex  and total number of records sent out to a file.

Below is my attempt but not great
#!/usr/bin/python
import sys
import csv
from collections import Counter

N=10
count=0
with open("file1") as f1:
for line in f1:
count+=1
print("Total Number of records read", count)
# I want to see the first few lines of the data


file1Name   x2x3
Alex1  F   2015/02/11
Alex2  M   2012/01/27
Alex3  F   2011/10/20
Alex4  M   .
Alex5  N   2003/11/14

file2
Name  x2x3
Bob1  1   2010-02-10
Bob2  2   2001-01-07
Bob3  1   2002-10-21
Bob4  2   2004-11-17
bob5  0   2009-11-19

file2
Namex2x3
Alexa1  0   12102013
Alexa2  2   20012007
Alexa3  1   11052002
Alexa4  2   26112004
Alexa5  2   15072009

Output to a file 
Name x2  x3
Alex1   2   20150211
Alex2   1   20120127
Alex3   2   20111020
Bob11   20100210
Bob22   20010107
Bob31   20021021
Bob42   20041117
Alexa2  2   20070120
Alexa3  1   20020511
Alexa4  2   20041126
Alexa5  2   20090715
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Christian Gollwitzer]

Am 14.03.16 um 21:31 schrieb BartC:

There are good reasons for wanting to do so. Try writing this function
in Python:

def swap(a,b):
 b,a = a,b

x="one"
y="two"
swap(x,y)

print (x,y)

so that it displays "two" "one".


The pervert thing is that this is nearly there:

def swap(a,b):
c=[]
c.append(*a)
a[:]=b[:]
b[:]=c[:]

x=["one"]
y=["two"]

swap(x,y)
print x
print y


Now with a similar example, I had created a bug some time ago. Try:

import numpy
def twice(x):
x*=2

a=5
b=numpy.array(5)

twice(a); twice(b)
print a
print b

This is actually one of the warts in Python. Yes there are some 
explanations with boxes and arrows and sticky notes and mutable and 
immutable values... but actually you understand it best if you know how 
CPython works and that a list is passed as a pointer.


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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Mark Lawrence]

On 14/03/2016 20:31, BartC wrote:

On 14/03/2016 19:45, alister wrote:

On Mon, 14 Mar 2016 14:43:22 +, BartC wrote:


On 13/03/2016 09:39, Steven D'Aprano wrote:

On Sun, 13 Mar 2016 04:54 am, BartC wrote:



Common sense tells you it is unlikely.


Perhaps your common sense is different from other people's common
sense. To me, and many other Python programmers, it's common sense that
being able to replace functions or methods on the fly is a useful
feature worth having. More on this below.

Perhaps this is an example of the "Blub Paradox":


Perhaps it's time to talk about something which many languages have, but
Python hasn't. Not as far as I know anyway.

That's references to names (sometimes called pointers). So if I write:

   a = 100 f(a)

then function f gets passed the value that a refers to, or 100 in this
case. But how do you pass 'a' itself?



Congratulations
you have just proven that you have faild in your understanimg of python @
stage 1 becuae you keep tying to us it a C

try the following

def test(x):
print (id(x)

a=100
print (id(a))
test(a)
a="Oops i was an idiot"
print (id(a))
test(a)

python always passes the object bound to a, not the value of a or a
pointer to a


Yes, and? I colloquially used 'value' instead of 'object', 'id' or
'reference'. The latter would added confusion as I'm talking about a
different kind of reference. And if you get rid of 'id' in your code,
you will get values displayed.

But how do you pass something that refers to a itself?

There are good reasons for wanting to do so. Try writing this function
in Python:

def swap(a,b):
 b,a = a,b

x="one"
y="two"
swap(x,y)

print (x,y)

so that it displays "two" "one".



Global.

--
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: Encapsulation in Python

[Ian Kelly]

On Mon, Mar 14, 2016 at 11:32 AM, Rick Johnson
 wrote:
> Ignoring Tkinter, which is a gawd awful mess, how would you
> re-organize the 3,656 symbols in OpenGL.GL into smaller
> modules, without dividing them up along some random or
> arbitrary lines?

In that particular case, I wouldn't, except possibly as an
implementation detail with the main OpenGL package importing the
contents of all its sub-packages into itself (and I think that if you
look at the PyOpenGL source you'll find that it's doing something
similar). It's following a well-documented API that is separate from
its Python wrapper. It's unfortunate that the only namespacing
considered in the design of that API was "everything starts with the
prefix gl", but that's what we're stuck with. Moving things around
would just confuse users who can't then find them where they expect.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Different sources of file

[Terry Reedy]

On 3/14/2016 4:56 PM, Val Krem via Python-list wrote:



Hi all,



I am made a little progress on using python.
I have five files to read from different sources  and concatenate them to one 
file.  From each file I want only to pick  few column  (x1, x2  and  x3). 
However, these columns say x3 was  a date in one file it was recorded as a 
character  (2015/12/26)  and in the other file it was records  (20151226)  and 
in the other file it was recorded as  (26122015). How do I standardized these 
into one form (mmdd-20151126). If there is no date then delete that record

2. The other variable x2. In one of the one files it was recorded as  "M" and 
"F". In the other  file  x3  is  1 for male and 2 for female.  So I want to change  all 
to 1 or 2. if this variable is out of range M / F or 1 or 2 then delete that record

3.  After doing all these I want combine all files into one  and send it to 
output.

Finally, do some statistics  such as number of records read from each file. 
Distribution of sex  and total number of records sent out to a file.

Below is my attempt but not great
#!/usr/bin/python
import sys
import csv
from collections import Counter

N=10
count=0
with open("file1") as f1:
for line in f1:
count+=1
print("Total Number of records read", count)
# I want to see the first few lines of the data


file1Name   x2x3
Alex1  F   2015/02/11
Alex2  M   2012/01/27
Alex3  F   2011/10/20
Alex4  M   .
Alex5  N   2003/11/14

file2
Name  x2x3
Bob1  1   2010-02-10
Bob2  2   2001-01-07
Bob3  1   2002-10-21
Bob4  2   2004-11-17
bob5  0   2009-11-19

file2
Namex2x3
Alexa1  0   12102013
Alexa2  2   20012007
Alexa3  1   11052002
Alexa4  2   26112004
Alexa5  2   15072009


Your examples are not comma separated values, rather column delimited 
values, so csv module is not appropriate nor note needed.  Assuming that 
your examples do not mislead,  slice out values by columns.


for line in file1:
name = line[0:5]
sex = line[7:8]
date = line[11:12]


outfile.write("{namespec} {sexspec} {datespec}\n"
.format(name, sex, date))

etc.


Output to a file
Name x2  x3
Alex1   2   20150211
Alex2   1   20120127
Alex3   2   20111020
Bob11   20100210
Bob22   20010107
Bob31   20021021
Bob42   20041117
Alexa2  2   20070120
Alexa3  1   20020511
Alexa4  2   20041126
Alexa5  2   20090715




--
Terry Jan Reedy

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 14/03/2016 21:00, Christian Gollwitzer wrote:

Am 14.03.16 um 21:31 schrieb BartC:

There are good reasons for wanting to do so. Try writing this function
in Python:

def swap(a,b):
 b,a = a,b

x="one"
y="two"
swap(x,y)

print (x,y)

so that it displays "two" "one".


The pervert thing is that this is nearly there:

def swap(a,b):
 c=[]
 c.append(*a)
 a[:]=b[:]
 b[:]=c[:]

x=["one"]
y=["two"]

swap(x,y)
print x

 print y

The list thing I've already tried. Although you've made it swap() more 
complicated than it need be. I used


def swap(a,b):
b[0],a[0]=a[0],b[0]

(Perhaps yours swapped the entire lists not just the first element? But 
that didn't work when I tried your code.)


The problem is that in general, x and y can be anything; maybe x is an 
element of a list, y is tuple. Even if by chance they were lists, then 
you'd want the entire list swapped.




Now with a similar example, I had created a bug some time ago.


It looks like you created a feature not a bug...

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

Re: Encapsulation in Python

[Mark Lawrence]

On 14/03/2016 21:09, Ian Kelly wrote:

On Mon, Mar 14, 2016 at 11:32 AM, Rick Johnson
 wrote:

Ignoring Tkinter, which is a gawd awful mess, how would you
re-organize the 3,656 symbols in OpenGL.GL into smaller
modules, without dividing them up along some random or
arbitrary lines?


In that particular case, I wouldn't, except possibly as an
implementation detail with the main OpenGL package importing the
contents of all its sub-packages into itself (and I think that if you
look at the PyOpenGL source you'll find that it's doing something
similar). It's following a well-documented API that is separate from
its Python wrapper. It's unfortunate that the only namespacing
considered in the design of that API was "everything starts with the
prefix gl", but that's what we're stuck with. Moving things around
would just confuse users who can't then find them where they expect.



If it was reorganised rr would claim that it had split the community in 
the same way that the disastrous migration from Python 2 to 3 has done. 
 The minor snag to his argument is that I'm not aware of any such split.


Python 2.8, RickedPython, and the latest entry into the race, 
BartCPython, all vapourware.  At least rr knows something about 
tkinter/IDLE, whereas the latter appears to know squat about anything. 
You can fool all of the programmers, all of the time?


--
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: Encapsulation in Python

[BartC]

On 14/03/2016 21:23, Mark Lawrence wrote:


Python 2.8, RickedPython, and the latest entry into the race,
BartCPython, all vapourware.


I'm not creating a new version of Python or CPython (you should have 
used an underscore).


But I do have considerable experience of creating dynamically-typed 
languages and writing byte-code interpreters for them. They are not 
vapourware.


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

OTish Wells Fargo sucks

[Seymore4Head]

Wells Fargo online will not allow you to change a payee's address. You
have to delete the account and re enter it.

I have had most of my bills on autopay for at least 15 years.  The
last utility company to make the change was the water company.  For
some reason their system could not take checks from my bank.  I had
the bank send the water company a check for 11.50 each month which was
a pretty close estimate of the actual bill and they adjusted the
actual amount plus or minus a few cents for around 2 years until they
"modernized" system.

Anyway, except for a few personal checks I have to write for home
maintenance, everything is automatic.  There are a few companies that
I have the bank issue checks from time to time.  There have been a
couple of times where the person/company actually changes the address,
but Wells Fargo does not allow you to change the address of a payee.
This sucks.  You would think the bank would issue you a unique number
for the payee and you should be able to change the address without
having to delete and remake the account.  The only reason I can think
of is lazy programming.  Do all banks make you delete your account to
change the payee address?


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

Re: Encapsulation in Python

[Mark Lawrence]

On 14/03/2016 22:07, BartC wrote:

On 14/03/2016 21:23, Mark Lawrence wrote:


Python 2.8, RickedPython, and the latest entry into the race,
BartCPython, all vapourware.


I'm not creating a new version of Python or CPython (you should have
used an underscore).

But I do have considerable experience of creating dynamically-typed
languages and writing byte-code interpreters for them. They are not
vapourware.



Really?  So why do you keep arguing, most notably with Steven D'Aprano, 
about the benefits of dynamic typing, whereby you appear to be 
completely against it?


The RUE kept stating that he was an expert in unicode, but never once 
provided a single shred of evidence to support his claim.  Until I see 
substantiated evidence from you I am going to state quite cleary that 
you've no idea, you're just another RUE.  Your dreadful piece of code 
published earlier today around a switch statement summed it up.  When 
are you running the profile that I asked for?


--
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: OTish Wells Fargo sucks

[Mark Lawrence]

On 14/03/2016 22:10, Seymore4Head wrote:

Wells Fargo online will not allow you to change a payee's address. You
have to delete the account and re enter it.

I have had most of my bills on autopay for at least 15 years.  The
last utility company to make the change was the water company.  For
some reason their system could not take checks from my bank.  I had
the bank send the water company a check for 11.50 each month which was
a pretty close estimate of the actual bill and they adjusted the
actual amount plus or minus a few cents for around 2 years until they
"modernized" system.

Anyway, except for a few personal checks I have to write for home
maintenance, everything is automatic.  There are a few companies that
I have the bank issue checks from time to time.  There have been a
couple of times where the person/company actually changes the address,
but Wells Fargo does not allow you to change the address of a payee.
This sucks.  You would think the bank would issue you a unique number
for the payee and you should be able to change the address without
having to delete and remake the account.  The only reason I can think
of is lazy programming.  Do all banks make you delete your account to
change the payee address?



Well if banks can't spell "modernised" or "cheques" correctly there is 
obviously no hope.  Perhaps we could get BartC to write a bit of code to 
sort this problem out?


Goes off looking for large pair of pliers with which to pull tongue from 
cheek.


--
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: OTish Wells Fargo sucks

[Joel Goldstick]

On Mon, Mar 14, 2016 at 6:25 PM, Mark Lawrence 
wrote:

> On 14/03/2016 22:10, Seymore4Head wrote:
>
>> Wells Fargo online will not allow you to change a payee's address. You
>> have to delete the account and re enter it.
>>
>> I have had most of my bills on autopay for at least 15 years.  The
>> last utility company to make the change was the water company.  For
>> some reason their system could not take checks from my bank.  I had
>> the bank send the water company a check for 11.50 each month which was
>> a pretty close estimate of the actual bill and they adjusted the
>> actual amount plus or minus a few cents for around 2 years until they
>> "modernized" system.
>>
>> Anyway, except for a few personal checks I have to write for home
>> maintenance, everything is automatic.  There are a few companies that
>> I have the bank issue checks from time to time.  There have been a
>> couple of times where the person/company actually changes the address,
>> but Wells Fargo does not allow you to change the address of a payee.
>> This sucks.  You would think the bank would issue you a unique number
>> for the payee and you should be able to change the address without
>> having to delete and remake the account.  The only reason I can think
>> of is lazy programming.  Do all banks make you delete your account to
>> change the payee address?
>>
>> A bit off topic? python?


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



-- 
Joel Goldstick
http://joelgoldstick.com/ 
http://cc-baseballstats.info/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation in Python

[BartC]

On 14/03/2016 22:20, Mark Lawrence wrote:

On 14/03/2016 22:07, BartC wrote:

On 14/03/2016 21:23, Mark Lawrence wrote:


Python 2.8, RickedPython, and the latest entry into the race,
BartCPython, all vapourware.


I'm not creating a new version of Python or CPython (you should have
used an underscore).

But I do have considerable experience of creating dynamically-typed
languages and writing byte-code interpreters for them. They are not
vapourware.



Really?  So why do you keep arguing, most notably with Steven D'Aprano,
about the benefits of dynamic typing, whereby you appear to be
completely against it?


I'm not against dynamic typing.

I'm against mutable, dynamic names, among other dynamic features that 
are well known to make Python hard to optimise, and which for me appear 
to give little added value.


 Your dreadful piece of code

published earlier today around a switch statement summed it up.


Was that in Python? It was /supposed/ to be dreadful. I was making a 
case for it to be supported directly.


> The RUE kept stating that he was an expert in unicode, but never once
> provided a single shred of evidence to support his claim.  Until I see
> substantiated evidence from you I am going to state quite cleary that
> you've no idea, you're just another RUE.

Sorry, I'm not going to do that, and I don't expect anyone here to have 
to do so either. You will have to take my posts as they are.


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

Re: Interaction between pygame and python

[Rick Johnson]

On Monday, March 14, 2016 at 2:06:02 PM UTC-5, Ian wrote:
> On Mon, Mar 14, 2016 at 10:53 AM, Rick Johnson
>  wrote:
> > If you download and run an installer, one that is
> > appropriate for your operating system and Python version,
> > everything will be taken care of for you.
> >
> > Since you are using Python 3.5.1 on a windows box, you'll
> > want to download and install the executable named
> > "pygame-1.9.1-py3.1.msi". You can get it here:
> >
> >   http://www.pygame.org/download.shtml
> 
> Unfortunately that installer is not appropriate for the OP's Python
> version. The downloads on the pygame site are horrifically
> out-of-date.

Well no wonder he's having such hard time, if a Pythonista like myself can't 
get it right, heck, then who can?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation in Python

[Rick Johnson]

On Sunday, March 13, 2016 at 6:35:40 PM UTC-5, Gregory Ewing wrote:
> Unless the module is doing something obscure, you can
> still find [it's source file] by following the chain of
> imports. [...] True, it's not *always* that easy, but in
> the vast majority of cases it is.

I agree you have a valid point, but i'll maintain that in no
way, does this help to relieve the confining nature of these
tightly wrapped "python module diapers", that we are all
forced to wear.

If our "Python motto" is to be, that we're "all adults",
and we can trust our "siblings", and hopefully, *ourselves*,
not to fiddle with aspects of our interfaces that are
considered private, and, private by nothing more, mind you,
than mere *convention*, then why do we take the opposite
approach for modules, and force *ALL* code into a mandatory
"one-size fits all" source file? Our ideology seems to be
inconsistent here. Either we are adults capable of defining
our own code, or we are immature babies who need mommy
Python to protect us from every evil. But we cannot claim to
be both.

And don't misunderstand me, neither form of convention is
"wrong". For instance, Java adopts a strict convention for
writing code, but Java never claimed that it was a language
that promoted "freedom". However, here in the Python
community, we are constantly blabbing about how free we
are, when in fact, our freedom is mostly a delusion. We need
to stop making these false "claims of freedom". Heck, the
only group of people more deluded about their own freedom,
are my fellow Americans (Sometimes i really hate this
country!)

Python does not encourage freedom.

Sure, we enjoy more "degrees of freedom" than say, your
average Java programmer, but we must still submit to the
many inconsistent whims of the Python interpreter. Outside
of indention, we can't define how our code blocks will be
structured. And, outside of nasty hacks, we can't decide how
our module source files will reflect run-time module
namespace. But most disturbing of all, there is no way
possible, to protect the internals of our interfaces from
public meddling.

Many programmers don't understand *WHY* internals need to be
protected. They will scoff at the idea, and they will claim
that, by limiting *THEIR* ability to meddle with internals,
*YOU* are robbing *THEM* of *THEIR* freedom. But what they
don't realize, is that, the only crime worse than failing to
create a proper interface, is to attempt to repair that
failure *EXTERNALLY*.

*ALL* repairs and *ALL* new features must be designed from
*WITHIN* the object that exposes the interface, and from
a strict internal perspective *ONLY*. Whether or not your
language allows it, the following contractual obligations
must *NEVER*, *EVER* be broken:

  (1) Callers can freely make requests to fetch or mutate a
  value, but they are forbidden from fetching and/or
  mutating the value directly. Only the object exposing the
  interface is capable of knowing how best to execute the
  request. If the caller finds that an accessor is missing,
  then the caller should beseech the source code maintainer
  to add the feature, or, they should add the feature
  themselves. But whoever adds the feature, they *MUST* do
  so in a manner that will not violate the basic contract
  between "callers" and "objects exposing an interface".

  (2) How a request is fulfilled, should be of no concern to
  an external caller. The only obligation the caller should
  expect of an interface, is that, when a formal request is
  sent, that a concerted attempt to fulfill the request will
  be made, and, if the request cannot be fulfilled, then a
  suitable explanation must be offered explaining why the
  request could not be fulfilled.

You see, the object exposing the interface is *ALWAYS*
submissive to the requests of any caller, but, if the caller
attempts to break the "accessor contract", by entering the
domain of the object exposing the interface, the object must
block the invader by any means necessary, up to, and
including, the fatal exception.

Basically, the object exposing the interface adopts an
attitude of: "Look, i'll do anything you ask me, so long
as you ask me one of the questions posted on the door, but
you have to make a formal request, you *CANNOT* just enter
this sacred place at will, and start meddling with my
levels and knobs, because if you do, you could cause a
chain reaction that will destroy the delicate balance of
our universe.

I've had the unfortunate experience of maintaining code that
did not utilize "strict interfacing contracts". Heck, for a
good example of what *NOT* to do, have a look at the
idlelib.

  (1) BAD STRUCTURE:  A clear hierarchical structure is
  missing. It's spaghetti code, plain and simple.

  (2) COMPONENT COUPLING: Components are too tightly
  coupled, preventing easy plug-in and/or removal.

  (3) EVENT BINDINGS FIASCO: Instead of creating a "central
  interface" for which *ALL* event bindings would route on
  their way to the main e

Re: Interaction between pygame and python

[Chris Angelico]

On Tue, Mar 15, 2016 at 9:58 AM, Rick Johnson
 wrote:
> On Monday, March 14, 2016 at 2:06:02 PM UTC-5, Ian wrote:
>> On Mon, Mar 14, 2016 at 10:53 AM, Rick Johnson
>>  wrote:
>> > If you download and run an installer, one that is
>> > appropriate for your operating system and Python version,
>> > everything will be taken care of for you.
>> >
>> > Since you are using Python 3.5.1 on a windows box, you'll
>> > want to download and install the executable named
>> > "pygame-1.9.1-py3.1.msi". You can get it here:
>> >
>> >   http://www.pygame.org/download.shtml
>>
>> Unfortunately that installer is not appropriate for the OP's Python
>> version. The downloads on the pygame site are horrifically
>> out-of-date.
>
> Well no wonder he's having such hard time, if a Pythonista like myself can't 
> get it right, heck, then who can?

Go where Terry recommended:

http://www.lfd.uci.edu/~gohlke/pythonlibs/

This is where you should go for Python module binaries for Windows, if
you don't want to compile your own.

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

Re: Encapsulation in Python

[Mark Lawrence]

On 14/03/2016 22:40, BartC wrote:

On 14/03/2016 22:20, Mark Lawrence wrote:

On 14/03/2016 22:07, BartC wrote:

On 14/03/2016 21:23, Mark Lawrence wrote:


Python 2.8, RickedPython, and the latest entry into the race,
BartCPython, all vapourware.


I'm not creating a new version of Python or CPython (you should have
used an underscore).

But I do have considerable experience of creating dynamically-typed
languages and writing byte-code interpreters for them. They are not
vapourware.



Really?  So why do you keep arguing, most notably with Steven D'Aprano,
about the benefits of dynamic typing, whereby you appear to be
completely against it?


I'm not against dynamic typing.

I'm against mutable, dynamic names, among other dynamic features that
are well known to make Python hard to optimise, and which for me appear
to give little added value.


There is no need to optimise python, it is fast enough.  For me every 
advantage of Python is that I can do what I like with it, when I like 
with it, and I'm not stuck in the dreadful straight jacket of the 
statically typed languages.  If someone wants to make it faster I'm not 
going to complain, but your obsession with speed is going to have me 
dying of laughter if this goes on much longer.




  Your dreadful piece of code

published earlier today around a switch statement summed it up.


Was that in Python? It was /supposed/ to be dreadful. I was making a
case for it to be supported directly.


You mean the huge great long list of hard coded function calls.  They 
are directly supported.  So is the loop.  Anything wrong with the Paul 
Rubin response?  And as my earlier link showed you often simply don't 
need a switch statement in an OO language.  Not much point providing 
something, much worse optimising it, if it isn't needed in the first place?




 > The RUE kept stating that he was an expert in unicode, but never once
 > provided a single shred of evidence to support his claim.  Until I see
 > substantiated evidence from you I am going to state quite cleary that
 > you've no idea, you're just another RUE.

Sorry, I'm not going to do that, and I don't expect anyone here to have
to do so either. You will have to take my posts as they are.



Drivel.  Any establised member of this community, or any other community 
for that matter, will always publish, unless, like the RUE, they've got 
something to hide.  So you're just a chicken.  Where do you buy the 
paint from for the streaks down your back?  Just in case you can't guess 
it is yellow.  I'll state the colour just in case your knowledge of 
colours is the same as your so called knowledge of computing, something 
of which I'm far from persuaded, on the grounds that speed simply is not 
the sole criteria for a language.


--
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: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Steven D'Aprano]

On Mon, 14 Mar 2016 06:39 am, BartC wrote:

> class switch(object):
>  value = None
>  def __new__(class_, value):
>  class_.value = value
>  return True
> 
> def case(*args):
>  return any((arg == switch.value for arg in args))

That's quite a clever use of a class. By clever, I mean imaginative, not
necessarily smart.


> I used it in my benchmark to replace the if-else chain checking three
> lots of ranges:
> 
> switch(c)
> if case(ord("A"),ord("B"),ord("C"),ord("D"),ord("E"),ord("F"),
>  ord("G"),ord("H"),ord("I"),ord("J"),ord("K"),ord("L"),
>  ord("M"),ord("N"),ord("O"),ord("P"),ord("Q"),ord("R"),
>  ord("S"),ord("T"),ord("U"),ord("V"),ord("W"),ord("X"),
>  ord("Y"),ord("Z")):
>  upper+=1
> elif case(ord("a"),ord("b"),ord("c"),ord("d"),ord("e"),ord("f"),
>  ord("g"),ord("h"),ord("i"),ord("j"),ord("k"),ord("l"),
>  ord("m"),ord("n"),ord("o"),ord("p"),ord("q"),ord("r"),
>  ord("s"),ord("t"),ord("u"),ord("v"),ord("w"),ord("x"),
>  ord("y"),ord("z")):
>  lower+=1
> elif case(ord("0"),ord("1"),ord("2"),ord("3"),ord("4"),ord("5"),
>ord("6"),ord("7"),ord("8"),ord("9")):
>  digits+=1
> else:
>  other+=1


Ai-ai-ai-aiye! 

What a mess! See what happens when you write assembly language in
Python? :-)


Try this instead:

c = chr(c)
if 'A' <= c <= 'Z':
upper += 1
elif 'a' <= c <= 'z':
lower += 1
elif '0' <= c <= '9':
digits += 1
else:
other += 1


But even better:

if c.isupper():
upper += 1
elif c islower():
lower += 1
elif c.isdigit():
digits += 1
else:
other += 1


which will work correctly for non-ASCII characters as well.



-- 
Steven

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

Re: Encapsulation in Python

[BartC]

On 14/03/2016 23:19, Mark Lawrence wrote:

On 14/03/2016 22:40, BartC wrote:



Was that in Python? It was /supposed/ to be dreadful. I was making a
case for it to be supported directly.


You mean the huge great long list of hard coded function calls.  They
are directly supported.  So is the loop.  Anything wrong with the Paul
Rubin response?


I tried it. It wasn't bad, but still 1/3 the speed of an if-elif chain 
with discrete range-checking.



And as my earlier link showed you often simply don't
need a switch statement in an OO language.  Not much point providing
something, much worse optimising it, if it isn't needed in the first place?


I disagree. And presumably so do others as there are so many different 
attempts to implement switch, with varying degrees of success. Here's 
how I do it outside Python:


 switch c
 when 'A'..'Z','a'..'z','_' then
 ++name
 when '0'..'9' then
 ++numeric
 when "()[]<>{}" then
 ++brackets
 else
 ++other
 end

Anything so terrible about that that Python needs to keep well clear of 
or that you think its users should be deprived of?



Sorry, I'm not going to do that, and I don't expect anyone here to have
to do so either. You will have to take my posts as they are.



Drivel.  Any establised member of this community, or any other community
for that matter, will always publish, unless, like the RUE, they've got
something to hide.  So you're just a chicken.  Where do you buy the
paint from for the streaks down your back?


OK, we've got another Rod Speed! He also gets a kick out of being rude 
and insulting to everyone.



on the grounds that speed simply is not
the sole criteria for a language.


I agree with you. But once you've got the language right, then there's 
no harm looking at performance. A switch statement like the above can be 
executed in a single byte-code.


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

Re: Different sources of file

[Wildman via Python-list]

On Mon, 14 Mar 2016 20:56:44 +, Val Krem wrote:

> #!/usr/bin/python

On some Linux systems python is installed in /usr/local/bin.
I would suggest the hash-bang below then python will run no
matter where it was installed...

#!/usr/bin/env python

As a python newbie myself, I can't really give you any
constructive comments on your code.

-- 
 GNU/Linux user #557453
May the Source be with you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Simple exercise

[Steven D'Aprano]

On Tue, 15 Mar 2016 02:06 am, Oscar Benjamin wrote:

> On 14 March 2016 at 14:35, Rick Johnson 
> wrote:
>>
>> I would strongly warn anyone against using the zip function
>> unless
> ...
>> I meant to say: absolutely, one hundred percent *SURE*, that
>> both sequences are of the same length, or, absolutely one
>> hundred percent *SURE*, that dropping values is not going to
>> matter. For that reason, i avoid the zip function like the
>> plague. I would much rather get an index error, than let an
>> error pass silently.
> 
> I also think it's unfortunate that zip silently discards items. 

Are you aware of itertools.zip_longest?

That makes it easy to build a zip_strict:

def zip_strict(*iterables):
pad = object()
for t in itertools.zip_longest(*iterables, fillvalue=pad):
if pad in t:
raise ValueError("iterables of different length")
yield t


Unfortunate or not, it seems to be quite common that "zip" (convolution)
discards items when sequences are of different lengths. I think the usual
intent is so that you can zip an infinite (or near infinite) sequence of
counters 1, 2, 3, 4, ... with the sequence you actually want, to get the
equivalent of Python's enumerate().

Clojure, Common Lisp, Haskell all halt on the shortest sequence, like
Python; D is configurable with a stopping policy:

(shortest, longest, requiresSameLength)

but the effect of these are not documented well.

http://dlang.org/phobos/std_range.html#zip

Ruby's zip pads missing values with nil, but only relative to the *first*
argument:

irb(main):001:0> a = [1, 2, 3]
=> [1, 2, 3]
irb(main):002:0> b = [10, 20]
=> [10, 20]
irb(main):003:0> a.zip(b)
=> [[1, 10], [2, 20], [3, nil]]
irb(main):004:0> b.zip(a)
=> [[10, 1], [20, 2]]


F# also has a zip function, but I don't know what it does.

Scheme doesn't appear to have a built-in zip function, but it is easily
written using map, giving the halt-on-shortest behaviour:

(define (zip l1 l2)(map list l1 l2))


See https://en.wikipedia.org/wiki/Convolution_%28computer_science%29



-- 
Steven

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

Re: Encapsulation in Python

[Chris Angelico]

On Tue, Mar 15, 2016 at 10:56 AM, BartC  wrote:
> I disagree. And presumably so do others as there are so many different
> attempts to implement switch, with varying degrees of success. Here's how I
> do it outside Python:
>
>  switch c
>  when 'A'..'Z','a'..'z','_' then
>  ++name
>  when '0'..'9' then
>  ++numeric
>  when "()[]<>{}" then
>  ++brackets
>  else
>  ++other
>  end
>
> Anything so terrible about that that Python needs to keep well clear of or
> that you think its users should be deprived of?

Yes: the complete lack of colons at the ends of lines that introduce
suites. This is utterly unacceptable in Python!

Seriously though - the one thing that I'm very concerned about here is
your brackets one. In Python, there's no reason to restrict 'switch'
to integers, so I would expect its semantics to be based on either
equality comparisons or inequality comparisons (possibly with a
requirement that all values be hashable); you could have something
like "when in " but a simple "when " would look to me
like it's testing for that entire string. (Don't forget that, in
Python, there's no difference between 'single quoted strings' and
"double quoted strings", as there is in C-like languages.)

Although... come to think of it, you could actually define it the
other way around: the 'when' statement checks if the current switch
object is contained within any of its arguments. Coupled with a
range-like object with its own literal syntax, that would pretty much
give you what you're looking at there. However, you'd need to have an
awkward notation for the cases where you _are_ looking for equality:

switch c:
when 'A'..'Z', 'a'..'z', ['_']:
++name

Or, in a long tree:

switch c:
when [1]:
...
when [2]:
...
when [3]:
...

Which could work. It'd be well-defined, and not unreasonable. It
would, however, be entirely predicated on a "comparison range" object
with a literal syntax:

class Range:
def __init__(self, start, stop):
self.start = start
self.stop = stop
def __contains__(self, obj):
return self.start <= obj <= self.stop
def __repr__(self):
return "%r..%r" % (self.start, self.stop)

But that's not overly hard either.

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

Re: Encapsulation in Python

[rurpy--- via Python-list]

On 03/14/2016 05:19 PM, Mark Lawrence wrote:
> On 14/03/2016 22:40, BartC wrote:
> > [...a polite and reasonable comment...]
>
> Drivel.  Any establised member of this community, or any other
> community for that matter, will always publish, unless, like the RUE,
> they've got something to hide.  So you're just a chicken.  Where do
> you buy the paint from for the streaks down your back?  Just in case
> you can't guess it is yellow.  I'll state the colour just in case
> your knowledge of colours is the same as your so called knowledge of
> computing, something of which I'm far from persuaded, on the grounds
> that speed simply is not the sole criteria for a language.

How much longer is the community going to ignore this nastiness?
These repeated vitriolic personal attacks are creating a poisonous
and hostile atmosphere that I and I'm sure many others don't want
to be exposed to when reading this group.

If I recall correctly, Mr. Lawrence was ejected from the developers
list a few years ago for the same kind of offensive behavior.

I suggest that both Mr. Lawrence and the list monitors review

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

and ask themselves if that document has any meaning at all.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation in Python

[Chris Angelico]

On Tue, Mar 15, 2016 at 11:17 AM, rurpy--- via Python-list
 wrote:
> On 03/14/2016 05:19 PM, Mark Lawrence wrote:
>> On 14/03/2016 22:40, BartC wrote:
>> > [...a polite and reasonable comment...]
>>
>> Drivel.  Any establised member of this community, or any other
>> community for that matter, will always publish, unless, like the RUE,
>> they've got something to hide.  So you're just a chicken.  Where do
>> you buy the paint from for the streaks down your back?  Just in case
>> you can't guess it is yellow.  I'll state the colour just in case
>> your knowledge of colours is the same as your so called knowledge of
>> computing, something of which I'm far from persuaded, on the grounds
>> that speed simply is not the sole criteria for a language.
>
> How much longer is the community going to ignore this nastiness?
> These repeated vitriolic personal attacks are creating a poisonous
> and hostile atmosphere that I and I'm sure many others don't want
> to be exposed to when reading this group.

The community has not ignored it; several people (myself included)
have told Mark off in public for what he's been saying lately.

> If I recall correctly, Mr. Lawrence was ejected from the developers
> list a few years ago for the same kind of offensive behavior.

This requires that the list admins do something. Regular members like
ourselves can't ban him. However, Mark should be aware that, yes, his
actions are not in line with the CoC.

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

Re: Encapsulation in Python

[Mark Lawrence]

On 14/03/2016 23:56, BartC wrote:

On 14/03/2016 23:19, Mark Lawrence wrote:

On 14/03/2016 22:40, BartC wrote:



Was that in Python? It was /supposed/ to be dreadful. I was making a
case for it to be supported directly.


You mean the huge great long list of hard coded function calls.  They
are directly supported.  So is the loop.  Anything wrong with the Paul
Rubin response?


I tried it. It wasn't bad, but still 1/3 the speed of an if-elif chain
with discrete range-checking.


I still haven't seen the profile that I asked for, so I've no idea what 
is taking the time.





And as my earlier link showed you often simply don't
need a switch statement in an OO language.  Not much point providing
something, much worse optimising it, if it isn't needed in the first
place?


I disagree. And presumably so do others as there are so many different
attempts to implement switch, with varying degrees of success. Here's
how I do it outside Python:

  switch c
  when 'A'..'Z','a'..'z','_' then
  ++name
  when '0'..'9' then
  ++numeric
  when "()[]<>{}" then
  ++brackets
  else
  ++other
  end

Anything so terrible about that that Python needs to keep well clear of
or that you think its users should be deprived of?


Yes, it is not even valid Python.  Switch has been rejected via at least 
one PEP and from what I see it adds nothing to the language, so let's 
deprive it from people who clearly don't need it in the first place.





Sorry, I'm not going to do that, and I don't expect anyone here to have
to do so either. You will have to take my posts as they are.



Drivel.  Any establised member of this community, or any other community
for that matter, will always publish, unless, like the RUE, they've got
something to hide.  So you're just a chicken.  Where do you buy the
paint from for the streaks down your back?


OK, we've got another Rod Speed! He also gets a kick out of being rude
and insulting to everyone.


I am only rude to people such as yourself who refuse to provide code, in 
fact anything, to support your case.  Your "benchmark" for the switch 
was yet another laughable farce, which only tested the function calls, 
building tuples, running loops, there was nothing to test with respect 
to the actual switch which was meant to be tested.  So just in case you 
missed it above, where is the profile for this test?  Do you even know 
what a profile is?





on the grounds that speed simply is not
the sole criteria for a language.


I agree with you. But once you've got the language right, then there's
no harm looking at performance. A switch statement like the above can be
executed in a single byte-code.



Really?  Then please show us all just how it can be done via a patch to 
the cPython code on the bug tracker.


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

Use of Lists, Tupples, or Sets in IF statement.

[jj0gen0info]

In Python is it possible to comparison-equate a variable to a List, Tupple, or 
Set and have it return True if the contents of the variable matches an element 
in the List, Tupple, or Set.

E.g.

x = "apple"

x-list = ["apple", "banana", "peach"]

If x == x-list:
print('Comparison is True')
else:
print('Comparison is False')

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 14/03/2016 23:24, Steven D'Aprano wrote:

On Mon, 14 Mar 2016 06:39 am, BartC wrote:


class switch(object):
  value = None
  def __new__(class_, value):
  class_.value = value
  return True

def case(*args):
  return any((arg == switch.value for arg in args))


That's quite a clever use of a class. By clever, I mean imaginative, not
necessarily smart.


I think so too. But it also looks inefficient.


Try this instead:

c = chr(c)
if 'A' <= c <= 'Z':
 upper += 1
elif 'a' <= c <= 'z':
 lower += 1
elif '0' <= c <= '9':
 digits += 1
else:
 other += 1


But even better:

if c.isupper():
 upper += 1
elif c islower():
 lower += 1
elif c.isdigit():
 digits += 1
else:
 other += 1


which will work correctly for non-ASCII characters as well.


Yes, but now you've destroyed my example!

A more realistic use of switch is shown below [not Python]. I've taken 
out the code for each section, including various nested switches, to 
show the test patterns better.


Now an if-elif chain won't perform as well.


doswitch p++^   # (looping switch)
when 'a'..'z','$','_' then
when '0'..'9' then
when 'A'..'Z' then
when '!' then
when '#' then
when '\\' then
when '{' then
when '}' then
when '.' then
when ',' then
when ';' then
when ':' then
when '(' then
when ')' then
when '[' then
when ']' then
when '|' then
when '^' then
when '@' then
when '?' then
when '£' then
when '~' then
when '¬' then
when '+' then
when '-' then
when '*' then
when '/' then
when '%' then
when '=' then
when '<' then
when '>' then
when '&' then
when '\'','`' then
when '"' then
when ' ','\t' then
when cr then
when lf then
when etx,0 then
else# unicode goes here...
end switch

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

Re: Use of Lists, Tupples, or Sets in IF statement.

[Joel Goldstick]

On Mon, Mar 14, 2016 at 8:26 PM,  wrote:

> In Python is it possible to comparison-equate a variable to a List,
> Tupple, or Set and have it return True if the contents of the variable
> matches an element in the List, Tupple, or Set.
>
> E.g.
>
> x = "apple"
>
> x-list = ["apple", "banana", "peach"]
>
> If x == x-list:
> print('Comparison is True')
> else:
> print('Comparison is False')
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>

if x in x-list


-- 
Joel Goldstick
http://joelgoldstick.com/ 
http://cc-baseballstats.info/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Use of Lists, Tupples, or Sets in IF statement.

[Chris Angelico]

On Tue, Mar 15, 2016 at 11:26 AM,   wrote:
> In Python is it possible to comparison-equate a variable to a List, Tupple, 
> or Set and have it return True if the contents of the variable matches an 
> element in the List, Tupple, or Set.
>
> E.g.
>
> x = "apple"
>
> x-list = ["apple", "banana", "peach"]
>
> If x == x-list:
> print('Comparison is True')
> else:
> print('Comparison is False')

Yep! What you're looking for is the "membership" operator. It's spelled "in":

>>> x = "apple"
>>> x_list = ["apple", "banana", "peach"]
>>>
>>> if x in x_list:
... print("That is a fruit.")
... else:
... print("That is not a fruit.")
...
That is a fruit.
>>> x = "jump"
>>> if x in x_list:
... print("That is a fruit.")
... else:
... print("You must be Chell.")
...
You must be Chell.


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

Re: Use of Lists, Tupples, or Sets in IF statement.

[Mark Lawrence]

On 15/03/2016 00:26, jj0gen0i...@gmail.com wrote:

In Python is it possible to comparison-equate a variable to a List, Tupple, or 
Set and have it return True if the contents of the variable matches an element 
in the List, Tupple, or Set.



It's actually "tuple", but what the heck :)


E.g.

x = "apple"

x-list = ["apple", "banana", "peach"]

If x == x-list:
 print('Comparison is True')
else:
 print('Comparison is False')



if x in x-list:
  ...


--
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: Encapsulation in Python

[Mark Lawrence]

On 15/03/2016 00:25, Chris Angelico wrote:

On Tue, Mar 15, 2016 at 11:17 AM, rurpy--- via Python-list
 wrote:

On 03/14/2016 05:19 PM, Mark Lawrence wrote:

On 14/03/2016 22:40, BartC wrote:

[...a polite and reasonable comment...]


Drivel.  Any establised member of this community, or any other
community for that matter, will always publish, unless, like the RUE,
they've got something to hide.  So you're just a chicken.  Where do
you buy the paint from for the streaks down your back?  Just in case
you can't guess it is yellow.  I'll state the colour just in case
your knowledge of colours is the same as your so called knowledge of
computing, something of which I'm far from persuaded, on the grounds
that speed simply is not the sole criteria for a language.


How much longer is the community going to ignore this nastiness?
These repeated vitriolic personal attacks are creating a poisonous
and hostile atmosphere that I and I'm sure many others don't want
to be exposed to when reading this group.


The community has not ignored it; several people (myself included)
have told Mark off in public for what he's been saying lately.


If I recall correctly, Mr. Lawrence was ejected from the developers
list a few years ago for the same kind of offensive behavior.


This requires that the list admins do something. Regular members like
ourselves can't ban him. However, Mark should be aware that, yes, his
actions are not in line with the CoC.

ChrisA



Same old story.  BartC spouts drivel, just like the RUE, or Nick "The 
Webmaster" Greek, I'm in trouble for pointing it out.  When he provides 
some *EVIDENCE* to back up his claims then I'll more than happily back 
off.  I do not intend holding my breath, and I do not intend backing 
off.  The Python community cannot let itself get into a position whereby 
crap is spewed by people and they're allowed to get away with it.  You 
lot might also be gutless cowards like he is, I'm not, and you might 
gather I'm not afraid to say so.


For example asking for benchmarks that back up his claims is exactly 
like asking the RUE for evidence to support his claims regarding the 
FSR, they simply never appear.  Why not?


--
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: Encapsulation in Python

[BartC]

On 15/03/2016 00:12, Chris Angelico wrote:

On Tue, Mar 15, 2016 at 10:56 AM, BartC  wrote:



  switch c
  when 'A'..'Z','a'..'z','_' then
  ++name



Anything so terrible about that that Python needs to keep well clear of or
that you think its users should be deprived of?


Yes: the complete lack of colons at the ends of lines that introduce
suites. This is utterly unacceptable in Python!

Seriously though - the one thing that I'm very concerned about here is
your brackets one.


Yeah, I'm not sure about that either. I'd already written:

 when '(', ')', 

when I thought having a string constant here would be neat, and 
implemented that just before posting.



In Python, there's no reason to restrict 'switch'
to integers, so I would expect its semantics to be based on either
equality comparisons or inequality comparisons


I use two forms of switch: one for integers only (very fast), and the 
other for any other values, which does tests in sequence.



(possibly with a
requirement that all values be hashable); you could have something
like "when in " but a simple "when " would look to me
like it's testing for that entire string. (Don't forget that, in
Python, there's no difference between 'single quoted strings' and
"double quoted strings", as there is in C-like languages.)

Although... come to think of it, you could actually define it the
other way around: the 'when' statement checks if the current switch
object is contained within any of its arguments. Coupled with a
range-like object with its own literal syntax, that would pretty much
give you what you're looking at there. However, you'd need to have an
awkward notation for the cases where you _are_ looking for equality:

switch c:
 when 'A'..'Z', 'a'..'z', ['_']:
 ++name

Or, in a long tree:

switch c:
 when [1]:
 ...
 when [2]:
 ...
 when [3]:
 ...

Which could work. It'd be well-defined, and not unreasonable. It
would, however, be entirely predicated on a "comparison range" object
with a literal syntax:

class Range:
 def __init__(self, start, stop):
 self.start = start
 self.stop = stop
 def __contains__(self, obj):
 return self.start <= obj <= self.stop
 def __repr__(self):
 return "%r..%r" % (self.start, self.stop)

But that's not overly hard either.


The tests I do for the more general switch are either equality, or 'in' 
for certain combinations of types (mainly testing integers for 
membership of ranges and sets. Sets are Pascal-style bit-sets).


I've also looked at the problem of when the choice might be ambiguous:

case x # general 'switch'
when y then
...

What happens when y is a list; should it do x==y or x in y? (Or both?)

I haven't solved that yet but it's never come up. When x is anything 
other than an int, you invariably want an equality test.


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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Mark Lawrence]

On 15/03/2016 00:25, BartC wrote:

[snip I really don't know what, it certainly isn't Python]


when etx,0 then
else# unicode goes here...
end switch



As John McEnroe famously said, "You cannot be serious".

--
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: Encapsulation in Python

[Chris Angelico]

On Tue, Mar 15, 2016 at 11:47 AM, Mark Lawrence  wrote:
> Same old story.  BartC spouts drivel, just like the RUE, or Nick "The
> Webmaster" Greek, I'm in trouble for pointing it out.  When he provides some
> *EVIDENCE* to back up his claims then I'll more than happily back off.  I do
> not intend holding my breath, and I do not intend backing off.  The Python
> community cannot let itself get into a position whereby crap is spewed by
> people and they're allowed to get away with it.  You lot might also be
> gutless cowards like he is, I'm not, and you might gather I'm not afraid to
> say so.
>
> For example asking for benchmarks that back up his claims is exactly like
> asking the RUE for evidence to support his claims regarding the FSR, they
> simply never appear.  Why not?

Asking for evidence is not against the CoC. It's *how* you are asking.
There has been more vitriol and acrimony on this list in the past week
than probably the entire previous year, and much of it has come from
your keyboard.

Perhaps you should take a few steps back, mute a few of these threads,
and don't respond to BartC for the next week. Let matters calm down a
little, particularly in your own head. The list will appreciate it.

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

Re: Encapsulation in Python

[Chris Angelico]

On Tue, Mar 15, 2016 at 11:54 AM, BartC  wrote:
>> In Python, there's no reason to restrict 'switch'
>> to integers, so I would expect its semantics to be based on either
>> equality comparisons or inequality comparisons
>
>
> I use two forms of switch: one for integers only (very fast), and the other
> for any other values, which does tests in sequence.

I'm not sure what you gain by restricting to integers that you
couldn't also gain with other hashable types. Can you elaborate on
these optimizations?

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

Re: Encapsulation in Python

[BartC]

On 15/03/2016 00:28, Mark Lawrence wrote:

On 14/03/2016 23:56, BartC wrote:



Anything so terrible about that that Python needs to keep well clear of
or that you think its users should be deprived of?


Yes, it is not even valid Python.  Switch has been rejected via at least
one PEP and from what I see it adds nothing to the language, so let's
deprive it from people who clearly don't need it in the first place.


Every time you need to test X against more than one other value, then 
you have a potential use for switch.


But yes you can do without switch if you have too. Same for many features.


I am only rude to people such as yourself who refuse to provide code, in
fact anything, to support your case.  Your "benchmark" for the switch
was yet another laughable farce, which only tested the function calls,
building tuples, running loops, there was nothing to test with respect
to the actual switch which was meant to be tested.  So just in case you
missed it above, where is the profile for this test?


I've shown the task. I'm sure you can also do some tests and show us 
some results.



I agree with you. But once you've got the language right, then there's
no harm looking at performance. A switch statement like the above can be
executed in a single byte-code.



Really?  Then please show us all just how it can be done via a patch to
the cPython code on the bug tracker.


The one-byte-code switch works when all case expressions are known at 
compile-time. It makes use of a jump-table within the byte-code.


The total sequence will be more than one byte-code, typically:

LOAD_FASTThe index
SWITCH   Jump to the right label

L5:  One of multiple labels
 ... Deal with the code in this branch
JUMP_ABSOLUTEBreak out of the switch

...  Provision is needed for the jump-table

But only one is needed for testing and dispatch. Now I've sketched it 
out, perhaps you can fill in the details for yourself... (I'm not 
getting involved in CPython development.)



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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Steven D'Aprano]

On Tue, 15 Mar 2016 01:43 am, BartC wrote:

> On 13/03/2016 09:39, Steven D'Aprano wrote:
>> On Sun, 13 Mar 2016 04:54 am, BartC wrote:
> 
>>> Common sense tells you it is unlikely.
>>
>> Perhaps your common sense is different from other people's common sense.
>> To me, and many other Python programmers, it's common sense that being
>> able to replace functions or methods on the fly is a useful feature worth
>> having. More on this below.
>>
>> Perhaps this is an example of the "Blub Paradox":
> 
> Perhaps it's time to talk about something which many languages have, but
> Python hasn't. Not as far as I know anyway.
> 
> That's references to names (sometimes called pointers). 

Calling them "pointers" is misleading and wrong. What you're referring to
are better known as "reference parameters".

C++ has such "call-by-reference", as does Pascal, using "var" parameters.
Algol uses something similar, but instead of call-by-reference it uses
call-by-name.

Like most modern languages, Python doesn't directly support
call-by-reference, but it is easily emulated with any mutable object. The
easiest is perhaps a single element list:

def f(ref):
ref[0] = 200

a = [100]
f(a)
print a[0]


but in general, such side-effects are frowned upon, and using a more
functional-style without side-effects is better. Why modify a in place by
magic when you can explicitly assign a new value to a?

Also, you might like to read this:

Does Python pass by reference or value?

http://import-that.dreamwidth.org/1130.html


-- 
Steven

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Steven D'Aprano]

On Tue, 15 Mar 2016 06:45 am, alister wrote:

> On Mon, 14 Mar 2016 14:43:22 +, BartC wrote:
[...]

> > Perhaps it's time to talk about something which many languages have, but
> > Python hasn't. Not as far as I know anyway.
> > 
>> That's references to names (sometimes called pointers). So if I write:
>> 
>>   a = 100 f(a)
>> 
>> then function f gets passed the value that a refers to, or 100 in this
>> case. But how do you pass 'a' itself?


> Congratulations
> you have just proven that you have faild in your understanimg of python @
> stage 1 becuae you keep tying to us it a C


Bart is specifically giving this as an example of something that *Python
cannot do*. Just like it says, in his first paragraph.

I think that, in a discussion of Python's strengths and weaknesses, it is
reasonable to discuss features of other languages that Python doesn't do.
Don't you?



[...]
> python always passes the object bound to a, not the value of a or a
> pointer to a

You might want to slow down a bit and think about this.

What is "the value of a"? Surely it must be *the object bound to a*. What
else could it be? In Python, all values are objects.




-- 
Steven

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

Re: Encapsulation in Python

[Chris Angelico]

On Tue, Mar 15, 2016 at 12:10 PM, BartC  wrote:
> The one-byte-code switch works when all case expressions are known at
> compile-time. It makes use of a jump-table within the byte-code.
>
> The total sequence will be more than one byte-code, typically:
>
> LOAD_FASTThe index
> SWITCH   Jump to the right label
> 
> L5:  One of multiple labels
>  ... Deal with the code in this branch
> JUMP_ABSOLUTEBreak out of the switch
>
> ...  Provision is needed for the jump-table
>
> But only one is needed for testing and dispatch. Now I've sketched it out,
> perhaps you can fill in the details for yourself... (I'm not getting
> involved in CPython development.)

Let's be fair here; anyone can make a single byte-code that does
arbitrary amounts of work. (Consider Python's CALL_FUNCTION or the old
PRINT_ITEM opcode.) How much work does SWITCH do here? Does the jump
table require that the possible case values be compact? If they're
not, how does it operate?

In Python, the most obvious way to do the repeated comparisons would
be a hash lookup. The SWITCH opcode could take a dictionary that maps
values to jump targets, with an 'else' target if the lookup fails, and
jump to that. It would actually be possible to implement this entirely
in an optimizer, with code written like this:

if x == 'asdf':
...
elif x == 'qwer':
...
elif x in ('zxcv', '1234'):
...
else:
...

Or, of course, it could get its own syntax.

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

Re: Encapsulation in Python

[BartC]

On 15/03/2016 00:58, Chris Angelico wrote:

On Tue, Mar 15, 2016 at 11:54 AM, BartC  wrote:

In Python, there's no reason to restrict 'switch'
to integers, so I would expect its semantics to be based on either
equality comparisons or inequality comparisons



I use two forms of switch: one for integers only (very fast), and the other
for any other values, which does tests in sequence.


I'm not sure what you gain by restricting to integers that you
couldn't also gain with other hashable types. Can you elaborate on
these optimizations?


The integer-switch is intended for use with jump-tables, which requires 
not only that the case expressions are known at compile-time, but that 
they don't span too large a range.


(When a jump-table couldn't be used, then there was a slightly different 
implementation which scanned a list of the case-expressions. Linearly; a 
binary search or hash look-up could be done too, but this was in fast 
static code, not interpreted, so was not too critical. But I don't use 
this any more anyway.)


For use with Python, because constant expressions are going to be 
limited, such a switch would only work with case expressions that are 
numeric literals or character constants, which have to be written 
b"A"[0] iirc. So rather limited unless someone introduces named 
constants at the same time...


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

Re: Use of Lists, Tupples, or Sets in IF statement.

[jj0gen0info]

Thanks to all for the responses.  Very new to Python, and thought there should 
be a way to do it.

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