Re: converting strings to hex

[James Harris]

"Mark H Harris"  wrote in message 
news:533e1b2e.5040...@gmail.com...
> On 4/3/14 9:10 PM, dave em wrote:
>>
>> I am taking a cryptography class and am having a
>> tough time with an assignment similar to this.
>>
>
> hi Dave, if your instructor wanted you to work on this with other people 
> she would have made it a group project and ordered pizza for everyone.
>
> I'll give you some credit, that last couple of folks that wanted help with 
> their homework here could not bring themselves to admit they wanted help 
> with their homework.   :)

YMMV but I thought the OP had done a good job before asking for help and 
then asked about only a tiny bit of it. Some just post a question!

>"HAL, please help me with my homework!"
>
>"I'm sorry, Dave, I can't do that..."
>
>"HAL!!?"
>
>"I'm sorry, Dave, I just can't do that..."

You might find this interesting.

  http://sundry.wikispaces.com/transcript-2001

James


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

Re: Yet Another Switch-Case Syntax Proposal

[Chris Angelico]

On Fri, Apr 4, 2014 at 2:13 PM, Ethan Furman  wrote:
> On 04/03/2014 08:09 PM, Chris Angelico wrote:
>>
>> On Fri, Apr 4, 2014 at 1:04 PM, MRAB  wrote:
>>>
>>> I thought [continue] went to the end of the loop, but because it's a
>>> loop, it
>>> just wraps around back to the top...
>>
>>
>> It goes to the bottom of the loop, and then the loop condition may or
>> may not send it to the top of the loop.
>
>
> *ahem*
>
> The loop condition is *at* the top of the loop;  if it was at the bottom it
> would be a do..until.  ;)

Well, if you go by the disassembly, Python does put the condition at
the top of the loop. But I've seen plenty of C compilers that invert
that - before the top of the loop it jumps down to the bottom, the
bottom has the condition, and the condition may or may not jump you up
to the top of the loop.

Semantics :)

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

Re: Switching between cmd.CMD instances

[Josh English]

On Wednesday, April 2, 2014 4:33:07 PM UTC-7, Jason Swails wrote:

> From there, you can implement a method interface in which the child Cmd 
> subclasses can call to indicate to BossCmd that do_exit has been called and 
> it should quit after the child's cmdloop returns.  So something like this:
>
> 

Hey, yeah. My previous responses didn't show up, or are delayed, or something.

Thank you, yes. This advice helped and rooting around the source code I 
realized that the Cmd.cmdqueue attribute is the easy way out:

import cmd

class BossCmd(cmd.Cmd):
def __init__(self):
cmd.Cmd.__init__(self)
self.prompt = 'Boss>'
self.exit_called_from_minion = False
self.minions = {}

def add_minion(self, name, cmder):
self.minions[name] = cmder

def do_exit(self, line):
return True

def postloop(self):
print "I mean it. I'm done"

def postcmd(self, stop, line):
# check if minion called for exit
if self.exit_called_from_minion:
stop = True
return stop

def do_submission(self, line):
if line:
self.minions['submission'].onecmd(line)
else:
self.minions['submission'].cmdloop()

def do_story(self, line):
if line:
self.minions['story'].onecmd(line)
else:
self.minions['story'].cmdloop()

class SubmissionCmd(cmd.Cmd):
def __init__(self, master = None):
cmd.Cmd.__init__(self)
self.prompt = 'Submission>'
self.master = master
if self.master:
self.master.add_minion('submission', self)

def do_done(self, line):
return True

def do_exit(self, line):
self.master.exit_called_from_minion = True
return True

def do_story(self, line):
if line:
self.master.minions['story'].onecmd(line)
else:
self.master.cmdqueue.append('story {}'.format(line))
return True


class StoryCmd(cmd.Cmd):
def __init__(self, master=None):
cmd.Cmd.__init__(self)
self.prompt = 'Story>'
self.master=master
if self.master:
self.master.add_minion('story', self)

def do_done(self, line):
return True

def do_exit(self, line):
elf.master.exit_called_from_minion = True
return True

def do_submission(self, line):
if line:
self.master.minions['submission'].onecmd(line)
else:
self.master.cmdqueue.append('submission {}'.format(line))
return True

Boss = BossCmd()
Sub = SubmissionCmd(Boss)
Story = StoryCmd(Boss)

Boss.cmdloop()


This gives me a flexible framework to bounce between Cmd instances at will, and 
quit the program from anywhere.

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

Re: Yet Another Switch-Case Syntax Proposal

[Ethan Furman]

On 04/03/2014 08:09 PM, Chris Angelico wrote:

On Fri, Apr 4, 2014 at 1:04 PM, MRAB  wrote:

I thought [continue] went to the end of the loop, but because it's a loop, it
just wraps around back to the top...


It goes to the bottom of the loop, and then the loop condition may or
may not send it to the top of the loop.


*ahem*

The loop condition is *at* the top of the loop;  if it was at the bottom it 
would be a do..until.  ;)

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

Re: converting strings to hex

[dave em]

> You haven't seen nothing yet, wait till M.L. catches you on the flip 
> 
> side for using gg.   {running for cover}


Who is ML?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: converting strings to hex

[Mark H Harris]

On 4/3/14 10:10 PM, dave em wrote:

Thanks, got it.  Sometimes the simple things can be difficult.

Dave



You haven't seen nothing yet, wait till M.L. catches you on the flip 
side for using gg.   {running for cover}


marcus


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

Re: converting strings to hex

[dave em]

On Thursday, April 3, 2014 8:31:42 PM UTC-6, Tim Chase wrote:
> On 2014-04-03 19:10, dave em wrote:
> 
> > So my first step is to compute the key.  I suspect my error below
> 
> > is because c1 is a float and m1 is a string but I don't know how to
> 
> > turn the string into a float.
> 
> 
> 
> For the record, "c1" in your example should be an integer/long
> 
> 
> 
> It sounds like you want the optional parameter to int() so you'd do
> 
> 
> 
> >>> hex_string = "My text message".encode("hex")
> 
> >>> hex_string
> 
> '4d792074657874206d657373616765'
> 
> >>> m1 = int(hex_string, 16)  # magic happens here
> 
> >>> m1
> 
> 402263600993355509170946582822086501L
> 
> >>> c1=0x6c73d5240a948c86981bc294814d 
> 
> >>> c1
> 
> 2199677439761906166135512011931981L
> 
> >>> k = m1 ^ c1
> 
> >>> k
> 
> 400239414552556350237329405469124136L
> 
> >>> hex(k) # as a string
> 
> '0x4d1553a14172e0acebfd68b1f5e628L'
> 
> 
> 
> 
> 
> -tkc

Thanks, got it.  Sometimes the simple things can be difficult.

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

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

[Mark H Harris]

On 4/3/14 2:43 PM, Marko Rauhamaa wrote:


What does computer science have to show of late? A better mutual
exclusion algorithm? Dancing trees?



Ok, cryptography has been pretty exciting. The back and forth between
feasibility and unfeasibility. The ongoing cat and mouse.


   Computer science is stuck right now. This is for two reasons:

   1) marketing (capitalism)

   2) software idea patents (obviously marketing related)

   Two things need to happen to 'unstick' computer science: 1) 
intellectual property law needs an overhaul and software idea patents 
must die, and 2) computer languages (software engineering, coding) needs 
to be taught as a liberal art beginning seriously in middle school as an 
integrated discipline (for sure by high school, and as an absolute in 
colleges).


   Computer science needs to be freed of the capitalistic strangle-hold 
which some corporations leverage over it. Innovation is thwarted because 
its the wrong capitalistic thing to do. Innovation is thwarted because 
of the asinine world-wide intellectual property law malfunction; 
software idea patents must die.


   Cryptography is particularly annoying. Mathematicians and algorithm 
specialists are ham-strung because of the GCHQ in the U.K. and the NSA 
in the States. Our governments DO NOT want computer science to move 
forward with cryptography!  God help the guy (people) who finally figure 
out how to determine the nth prime, or figure out how to factor really 
HUGE prime numbers easily on a desktop computer (not likely to happen 
anytime soon, but for sure NOT going to happen with the NSA & GCHQ 
looking over everyone's shoulders.


   Well, as everyone pointed out integers are the focal point for 
crypto. But, what if the focal point should be 'decimal' (really large 
very fast decimals).  --- which are useful for constructing certain 
integers and ... dream with me here.   Whatever it will take WILL 
require a paradigm shift, and it will require that we stand up and 
defend our right to pursue the course. Everyone has a right to digital 
privacy. Computer science is the way forward.



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

Re: Yet Another Switch-Case Syntax Proposal

[Chris Angelico]

On Fri, Apr 4, 2014 at 1:04 PM, MRAB  wrote:
> I thought [continue] went to the end of the loop, but because it's a loop, it
> just wraps around back to the top...

It goes to the bottom of the loop, and then the loop condition may or
may not send it to the top of the loop.

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

Re: Yet Another Switch-Case Syntax Proposal

[Ethan Furman]

On 04/03/2014 07:04 PM, MRAB wrote:

On 2014-04-03 19:23, Ethan Furman wrote:

On 04/03/2014 09:02 AM, Lucas Malor wrote:


In reply to Ian Kelly:


Instead of disabling fallthrough by default, why not disable it all together?


I was tempted but there are cases in which it's useful. An example

switch day casein ("Monday", "Thursday", "Wednesday", "Tuesday", "Friday"):
 gotowork = True
 continue
casein ("Monday", "Thursday", "Wednesday", "Tuesday", "Friday"):
 daytype = "ferial"
casein ("Saturday", "Sunday")
 daytype = "festive"



Absolutely not.  Currently, the 'continue' key word means "stop processing and go 
back to the beginning".  You would
have it mean "keep going forward".  Thus 'continue' would mean both "go backwards" and 
"go forwards" and would lead to
unnecessary confusion.


I thought it went to the end of the loop, but because it's a loop, it
just wraps around back to the top...


*sigh*  I see you are already confused.  ;)

H I think that would be more like 'skip' as in 'skip to the end'...

Either way, though, 'continue' would mean two very different things:

 - skip everything between here and the end of the loop

 - don't skip everything between here and the end of the case

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

Re: converting strings to hex

[Mark H Harris]

On 4/3/14 9:10 PM, dave em wrote:


I am taking a cryptography class and am having a
tough time with an assignment similar to this.



hi Dave, if your instructor wanted you to work on this with other people 
she would have made it a group project and ordered pizza for everyone.


I'll give you some credit, that last couple of folks that wanted help 
with their homework here could not bring themselves to admit they wanted 
help with their homework.   :)


   "HAL, please help me with my homework!"

   "I'm sorry, Dave, I can't do that..."

   "HAL!!?"

   "I'm sorry, Dave, I just can't do that..."


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

Re: converting strings to hex

[Tim Chase]

On 2014-04-03 19:10, dave em wrote:
> So my first step is to compute the key.  I suspect my error below
> is because c1 is a float and m1 is a string but I don't know how to
> turn the string into a float.

For the record, "c1" in your example should be an integer/long

It sounds like you want the optional parameter to int() so you'd do

>>> hex_string = "My text message".encode("hex")
>>> hex_string
'4d792074657874206d657373616765'
>>> m1 = int(hex_string, 16)  # magic happens here
>>> m1
402263600993355509170946582822086501L
>>> c1=0x6c73d5240a948c86981bc294814d 
>>> c1
2199677439761906166135512011931981L
>>> k = m1 ^ c1
>>> k
400239414552556350237329405469124136L
>>> hex(k) # as a string
'0x4d1553a14172e0acebfd68b1f5e628L'


-tkc




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

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

[Mark H Harris]

On 4/3/14 9:07 PM, alex23 wrote:

On 4/04/2014 2:38 AM, Mark H Harris wrote:

If I speak of the python community, and I rarely do


Maybe you speak "of" them rarely but you claim to speak "for" them
fairly often.


   I am sorry, and I do apologize (genuinely). I knowingly speak for my 
users, because I have their input (positive and negative) and because I 
have a list of likes|dislikes.
   I don't knowingly speak 'for' the python community; except that I 
can see that speaking about|for 'python' the interpreter might get 
interpreted as speaking of|for the 'python community'.  If that occurs I 
assure you that its not intentional (mostly).



Python3 is not perfect; but python3 is *way* more consistent than
python2 and consequently *way* more useful than python2.



It's possible for something to become "more useful" and for the original
to *also* be useful: Py2 old-style classes were useful even though
new-style classes were more so. Plone uses Py2's unicode extensively and
at no point have I thought it "useless".


   Oh, I agree. Again, think of 'useful' on a continuum where 
comparison and contrast is king and queen, and where 'more useful' does 
not make 'less useful' obsolete. Again, prior to the C accelerated 
decimal module for python3.3 I did not use decimal (too slow). That does 
not mean that decimal was 'useless' (I am using it on 2.7.2 with QPython 
on Android with pdeclib). But something happened, decimal became fast 
enough that it is truly 'useful' enough (on the continuum) to be used 
IMHO as default. (that is all rhetorical; no need to argue it)


   Now, about Python2.  It has not died.  It appears to be 'useful'. 
The perceived reality is that Python2 is 'useful'.  Or, is it as I 
perceive it, python2 is embedded in so many places that it must be 
maintained for a long time because so many code(s) will break otherwise?

Not so much 'useful' as 'used,' so that it is never sacked.
Or, is it really that python2 is so much more 'suitable for a particular 
purpose' ('useful') that certain folks just don't want to use python3? 
Beats me; the community will have to decide.


marcus



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

converting strings to hex

[dave em]

Hello,

I am taking a cryptography class and am having a tough time with an assignment 
similar to this.

Given plain text message 1 and cipher 1 compute cipher 2 for message 2

Work flow will be:
- figure out the key
- use key to compute c2

So this is what I have so far and am getting nowhere fast.  I could use a 
little help on this one.

So my first step is to compute the key.  I suspect my error below is because c1 
is a float and m1 is a string but I don't know how to turn the string into a 
float.


  Python 2.7###

m1text="my test message"
print( m1text + ' in hex is ')
print m1text.encode("hex")
m1 = m1text.encode("hex")
c1=0x6c73d5240a948c86981bc294814d 

k=m1^c1
print( 'the key = ' )
print hex(k)

This code yields the following:

my test message in hex is 
6d792074657374206d657373616765
Traceback (most recent call last):
  File "/media/.../Crypto/Attackv2.py", line 10, in 
k=m1^c1
TypeError: unsupported operand type(s) for ^: 'str' and 'long'

Any help is most appreciated.

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

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

[Mark H Harris]

On 4/3/14 5:43 PM, Chris Angelico wrote:


So your definition of "useful" for the Decimal module is "fast" and
your definition of "useful" for Unicode is "mandated into use".


   No. I did not define 'useful'.  I placed 'useful' on a continuum 
whereby 'useful' is non definitive & relative. Go read it again. Decimal 
became practical (due to performance enhancement) and therefore 'bumped 
up' on the 'useful' continuum. Unicode in python3 is more 'useful' than 
in python2; yet, useful for a given purpose in *both* (based on user 
preference and "suitability for a particular purpose")


   One of the reasons that many of us include a boiler plate legal 
disclaimer about useability in our open source is that "suitable for a 
particular purpose", ehem 'useful,' is entirely in the eye(s) of the 
beholder.



Python is
useful in that I am able to wield it to solve my problems.


   Python is 'useful' because I am able to solve my computational 
problems with it. Python3 is *more* 'useful' than Python2 for my 
purposes of computability and computational problem solving--- don't 
look for it in the dictionary.  'Useful' is as 'useful' does. 'Useful' 
is as I perceive it.  'Useful' is also as you perceive it.
   Immanuel kant said, "Perception is reality". 'Useful' is perceived 
reality--- a continuum between to extremes--- useless on the one hand, 
and flexible and all-powerful on the other.
   Oh, and by the by, my perceived continuum will 'look' different than 
your perceived continuum. In fact, they might be overlapping but 
probably will be non intersecting (all depending upon our own perceptions).


marcus

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

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

[alex23]

On 4/04/2014 2:38 AM, Mark H Harris wrote:

If I speak of the python community, and I rarely do


Maybe you speak "of" them rarely but you claim to speak "for" them 
fairly often.



Python3 is not perfect; but python3 is *way* more consistent than
python2 and consequently *way* more useful than python2.


It's possible for something to become "more useful" and for the original 
to *also* be useful: Py2 old-style classes were useful even though 
new-style classes were more so. Plone uses Py2's unicode extensively and 
at no point have I thought it "useless".

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

Re: Yet Another Switch-Case Syntax Proposal

[MRAB]

On 2014-04-03 19:23, Ethan Furman wrote:

On 04/03/2014 09:02 AM, Lucas Malor wrote:


In reply to Ian Kelly:


Instead of disabling fallthrough by default, why not disable it all together?


I was tempted but there are cases in which it's useful. An example

switch day casein ("Monday", "Thursday", "Wednesday", "Tuesday", "Friday"):
 gotowork = True
 continue
casein ("Monday", "Thursday", "Wednesday", "Tuesday", "Friday"):
 daytype = "ferial"
casein ("Saturday", "Sunday")
 daytype = "festive"



Absolutely not.  Currently, the 'continue' key word means "stop processing and go 
back to the beginning".  You would
have it mean "keep going forward".  Thus 'continue' would mean both "go backwards" and 
"go forwards" and would lead to
unnecessary confusion.


I thought it went to the end of the loop, but because it's a loop, it
just wraps around back to the top...
--
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode Chars in Windows Path

[David]

On 4 April 2014 12:16, Chris Angelico  wrote:
> On Fri, Apr 4, 2014 at 11:15 AM, David  wrote:
>> On 4 April 2014 01:17, Chris Angelico  wrote:
>>>
>>> -- Get info on all .pyc files in a directory and all its subdirectories --
>>> C:\>dir some_directory\*.pyc /s
>>> $ ls -l `find some_directory -name \*.pyc`
>>>
>>> Except that the ls version there can't handle names with spaces in
>>> them, so you need to faff around with null termination and stuff.
>>
>> Nooo, that stinks! There's no need to abuse 'find' like that, unless
>> the version you have is truly ancient. Null termination is only
>> necessary to pass 'find' results *via the shell*. Instead, ask 'find'
>> to invoke the task itself.
>>
>> The simplest way is:
>>
>> find some_directory -name '*.pyc' -ls
>>
>> 'find' is the tool to use for *finding* things, not 'ls', which is
>> intended for terminal display of directory information.
>
> I used ls only as a first example, and then picked up an extremely
> common next example (deleting files). It so happens that find can
> '-delete' its found files, but my point is that on DOS/Windows, every
> command has to explicitly support subdirectories. If, instead, the
> 'find' command has to explicitly support everything you might want to
> do to files, that's even worse! So we need an execution form...
>
>> If you require a particular feature of 'ls', or any other command, you
>> can ask 'find' to invoke it directly (not via a shell):
>>
>> find some_directory -name '*.pyc' -exec ls -l {} \;
>
> ... which this looks like, but it's not equivalent.

> That will execute
> 'ls -l' once for each file. You can tell, because the columns aren't
> aligned; for anything more complicated than simply 'ls -l', you
> potentially destroy any chance at bulk operations.

Thanks for elaborating that point. But still ...

> equivalent it *must* pass all the args to a single invocation of the
> program. You need to instead use xargs if you want it to be
> equivalent, and it's now getting to be quite an incantation:
>
> find some_directory -name \*.pyc -print0|xargs -0 ls -l
>
> And *that* is equivalent to the original, but it's way *way* longer
> and less convenient, which was my point.

If you are not already aware, it might interest you that 'find' in
(GNU findutils) 4.4.2. has

 -- Action: -execdir command {} +
 This works as for `-execdir command ;', except that the `{}' at
 the end of the command is expanded to a list of names of matching
 files.  This expansion is done in such a way as to avoid exceeding
 the maximum command line length available on the system.  Only one
 `{}' is allowed within the command, and it must appear at the end,
 immediately before the `+'.  A `+' appearing in any position other
 than immediately after `{}' is not considered to be special (that
 is, it does not terminate the command).

I believe that achieves the goal, without involving the shell.

It also has an -exec equivalent that works the same but has an
unrelated security issue and not recommended.

But if that '+' instead of ';' feature is not available on the
target system, then as far as I am aware it would be necessary
to use xargs as you say.

Anyway, the two points I wished to contribute are:

1) It is preferable to avoid shell command substitutions (the
backticks in the first example) and expansions where possible.

2) My observations on 'find' syntax, for anyone interested.

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

Re: Compact way to assign values by slicing list in Python

[alex23]

On 3/04/2014 11:50 PM, Marco Buttu wrote:

I prefere this one:

bar = ['a','b','c','x','y','z']
v1, _, _, v2, v3, _ = bar

I also like the solution with itemgetter:

v1, v2, v3 = itemgetter(0, 3, 4)(bar)

but I think it is less readable than the previous one


What if you wanted the 2nd, 37th, and 1007th items from a list?

Personally, I find the 2nd form far more readable, once I got past my 
initial surprise that it would access a list of items.


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

Re: COM Server data from python

[Chris Farrow]

On Wednesday, April 2, 2014 8:39:01 AM UTC-5, schapm...@gmail.com wrote:
> I am attempting to provide a bit of data through a com server I did a 
> comparison of speed of my COM interface to ADODB and It seems massively 
> slower.  I'm not sure if there is something I need to adjust or maybe that I 
> am making so many calls to the COM server that each call takes time and 
> possibly ADO is just buffering some data in chunks to my code.  This is 
> mainly for an excel add-on that has not possibility to connect to mongodb 
> except through an interface like this.
> 
> 
> 
>   I thought it was not really a big deal until I tested larger amounts of 
> data and the speed took a nose dive.  For instance 10,000 records just to 
> walk through and pull a couple fields.  ADO on the exact same data took only 
> 1.5 seconds where my python code took close to 58 seconds to do the same 
> thing.  I've played around with design etc.
> 
> 
> 
>   When i test the same code directly from python I get the same result if not 
> better than I did with ADO.  Is there some bit of COM magic that I am 
> missing.  Or is this because python is having to do more behind the scenes?
> 
> 
> 
> Thanks

Hi,

Did you implement your server using win32com? You might be better off looking 
for help on the python-win32 mailing list [1].

Regards,

Chris

[1] https://mail.python.org/pipermail/python-win32/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode Chars in Windows Path

[Chris Angelico]

On Fri, Apr 4, 2014 at 11:15 AM, David  wrote:
> On 4 April 2014 01:17, Chris Angelico  wrote:
>>
>> -- Get info on all .pyc files in a directory and all its subdirectories --
>> C:\>dir some_directory\*.pyc /s
>> $ ls -l `find some_directory -name \*.pyc`
>>
>> Except that the ls version there can't handle names with spaces in
>> them, so you need to faff around with null termination and stuff.
>
> Nooo, that stinks! There's no need to abuse 'find' like that, unless
> the version you have is truly ancient. Null termination is only
> necessary to pass 'find' results *via the shell*. Instead, ask 'find'
> to invoke the task itself.
>
> The simplest way is:
>
> find some_directory -name '*.pyc' -ls
>
> 'find' is the tool to use for *finding* things, not 'ls', which is
> intended for terminal display of directory information.

I used ls only as a first example, and then picked up an extremely
common next example (deleting files). It so happens that find can
'-delete' its found files, but my point is that on DOS/Windows, every
command has to explicitly support subdirectories. If, instead, the
'find' command has to explicitly support everything you might want to
do to files, that's even worse! So we need an execution form...

> If you require a particular feature of 'ls', or any other command, you
> can ask 'find' to invoke it directly (not via a shell):
>
> find some_directory -name '*.pyc' -exec ls -l {} \;

... which this looks like, but it's not equivalent. That will execute
'ls -l' once for each file. You can tell, because the columns aren't
aligned; for anything more complicated than simply 'ls -l', you
potentially destroy any chance at bulk operations. No, to be
equivalent it *must* pass all the args to a single invocation of the
program. You need to instead use xargs if you want it to be
equivalent, and it's now getting to be quite an incantation:

find some_directory -name \*.pyc -print0|xargs -0 ls -l

And *that* is equivalent to the original, but it's way *way* longer
and less convenient, which was my point. Plus, it's extremely tempting
to shorten that, because this will almost always work:

find some_directory -name \*.pyc|xargs ls -l

But it'll fail if you have newlines in file names. It'd probably work
every time you try it, and then you'll put that in a script and boom,
it stops working. (That's what I meant by "faffing about with null
termination". You have to go through an extra level of indirection,
making the command fairly unwieldy.)

> I know this is off-topic but because I learn so much from the
> countless terrific contributions to this list from Chris (and others)
> with wide expertise, I am motivated to give something back when I can.

Definitely! This is how we all learn :) And thank you, glad to hear that.

> And given that in the past I spent a little time and effort and
> eventually understood this, I summarise it here hoping it helps
> someone else. The unix-style tools are far more capable than the
> Microsoft shell when used as intended.

More specifically, the Unix model ("each tool should do one thing and
do it well") tends to make for more combinable tools. The DOS style
requires every program to reimplement the same directory-search
functionality, and then requires the user to figure out how it's been
written in this form ("zip -r" (or is it "zip -R"...), "dir /s", "del
/s", etc, etc). The Unix style requires applications to accept
arbitrary numbers of arguments (which they probably would anyway), and
then requires the user to learn some incantations that will then work
anywhere. If you're writing a script, you should probably use the
-print0|xargs -0 method (unless you already require bash for some
other reason); interactively, you more likely want to enable globstar
and use the much shorter double-star notation. Either way, it works
for any program, and that is indeed "far more capable".

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

Re: Default mutable parameters in functions

[Mark Lawrence]

On 03/04/2014 19:49, fbick...@gmail.com wrote:

Hi all,

So I was reading about default values for functions and spied this:


[snip]



I was rather expecting it to start with 4!


I just wish I had a quid for every time somebody expects something out 
of Python, that way I'd have retired years ago.  At least here it's not 
accompanied by "as that's how it works in ".


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Unicode Chars in Windows Path

[David]

On 4 April 2014 01:17, Chris Angelico  wrote:
>
> -- Get info on all .pyc files in a directory and all its subdirectories --
> C:\>dir some_directory\*.pyc /s
> $ ls -l `find some_directory -name \*.pyc`
>
> Except that the ls version there can't handle names with spaces in
> them, so you need to faff around with null termination and stuff.

Nooo, that stinks! There's no need to abuse 'find' like that, unless
the version you have is truly ancient. Null termination is only
necessary to pass 'find' results *via the shell*. Instead, ask 'find'
to invoke the task itself.

The simplest way is:

find some_directory -name '*.pyc' -ls

'find' is the tool to use for *finding* things, not 'ls', which is
intended for terminal display of directory information.

If you require a particular feature of 'ls', or any other command, you
can ask 'find' to invoke it directly (not via a shell):

find some_directory -name '*.pyc' -exec ls -l {} \;

'Find' is widely under utilised and poorly understood because its
command line syntax is extremely confusing compared to other tools,
plus its documentation compounds the confusion. For anyone interested,
I offer these key insights:

Most important to understand is that the -name, -exec and -ls that I
used above (for example) are *not* command-line "options". Even though
they look like command-line options, they aren't. They are part of an
*expression* in 'find' syntax. And the crucial difference is that the
expression is order-dependent. So unlike most other commands, it is a
mistake to put them in arbitrary order.

Also annoyingly, the -exec syntax utilises characters that must be
escaped from shell processing. This is more arcane knowledge that just
frustrates people when they are in a rush to get something done.

In fact, the only command-line *options* that 'find' takes are -H -L
-P -D and -O, but these are rarely used. They come *before* the
directory name(s). Everything that comes after the directory name is
part of a 'find' expression.

But, the most confusing thing of all, in the 'find' documentation,
expressions are composed of tests, actions, and ... options! These
so-called options are expression-options, not command-line-options. No
wonder everyone's confused, when one word describes two
similar-looking but behaviourally different things!

So 'info find' must be read very carefully indeed. But it is
worthwhile, because in the model of "do one thing and do it well",
'find' is the tool intended for such tasks, rather than expecting
these capabilities to be built into all other command line utilities.

I know this is off-topic but because I learn so much from the
countless terrific contributions to this list from Chris (and others)
with wide expertise, I am motivated to give something back when I can.
And given that in the past I spent a little time and effort and
eventually understood this, I summarise it here hoping it helps
someone else. The unix-style tools are far more capable than the
Microsoft shell when used as intended.

There is good documentation on find at: http://mywiki.wooledge.org/UsingFind
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Yet Another Switch-Case Syntax Proposal

[Chris Angelico]

On Fri, Apr 4, 2014 at 10:03 AM, Mark Lawrence  wrote:
> Please don't take this personally, but there's more chance of me being the
> first ever World President than of anybody getting a switch/case statement
> past the BDFL.

The language in PEP 3103 (written by Guido) doesn't suggest this to
me. But maybe that's just being diplomatic.

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

Re: Yet Another Switch-Case Syntax Proposal

[Mark Lawrence]

On 02/04/2014 15:53, Lucas Malor wrote:

Hi all. I would proposeto you all a switch-case syntax for Python. I already 
read PEP 3103 and I'm not completely satisfied by any of the proposed 
solutions. This is my proposal:

switch_stmt ::=  "switch" identifier "case" expression_list ":" suite
 ("case" expression_list ":" suite)*
 ["else" ":" suite]

or, more simply:



switch x case var1:
 
case var2:
 ...
case var3:
 ...
else:
 ...



Please don't take this personally, but there's more chance of me being 
the first ever World President than of anybody getting a switch/case 
statement past the BDFL.


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Two Questions about Python on Windows

[Mark Lawrence]

On 03/04/2014 23:41, Ian Kelly wrote:

On Thu, Apr 3, 2014 at 2:15 PM, Mark Lawrence  wrote:

On 03/04/2014 18:54, Ian Kelly wrote:



On Apr 3, 2014 11:12 AM, "Walter Hurry" mailto:walterhu...@gmail.com>> wrote:
  >
  > Normally my Python development is done on FreeBSD and Linux. I know
that on *ix I simply have to make foo.py executable (the shebang line is
present, of course) to make it runnable.
  >
  > For my son's school assignment, I have to help him with Python for
Windows.
  >
  > As I understand it, on Windows a .py file is not executable, so I
need to run 'python foo py', or use a .pyw file.
  >
  > Question 1: Do I make a .pyw file simply by copying or renaming
foo.py to foo.pyw?

Yes. The only distinction between .py and .pyw is that the Python
installer associates the former with Python.exe and the latter with
Pythonw.exe. Pythonw runs the script without creating a console window
for stdin/stdout.



Not with more modern versions of Python.

c:\Users\Mark>assoc .py
.py=Python.File

c:\Users\Mark>ftype Python.File
Python.File="C:\Windows\py.exe" "%1" %*


Which ultimately calls some version of python.exe.


c:\Users\Mark>assoc .pyw
.pyw=Python.NoConFile

c:\Users\Mark>ftype Python.NoConFile
Python.NoConFile="C:\Windows\pyw.exe" "%1" %*


Which ultimately calls some version of pythonw.exe.

I elided that detail because it wasn't relevant to the question at hand.



Yes, I regretted how badly I worded the above the second I hit the send 
button.


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Examples of modern GUI python programms

[Chris Angelico]

On Fri, Apr 4, 2014 at 9:31 AM, Sturla Molden  wrote:
> Chris Angelico  wrote:
>
>> Where? I can't see it. The home page redirects me to /news.html which
>> doesn't say anything about GPL (other than in its collection of tags,
>> which seem to be for finding other people's projects - that is,
>> clicking that link takes you to a list of all pygame-using projects
>> that are GPL'd); on the Documentation page, the license is clearly
>> LGPL.
>>
>
> http://www.pygame.org/wiki/about
>
> "Pygame is free. Released under the GPL License, you can create open
> source, free, freeware, shareware, and commercial games with it. See the
> licence for full details."
>
> But as pointed out, it seems to be a typo.

Ah yes, I see. That should probably be raised as a bug.

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

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

[Chris Angelico]

On Fri, Apr 4, 2014 at 3:38 AM, Mark H Harris  wrote:
>'Useful' must always be taken in context, and also contextually evaluated
> with an on-going methodology which constantly informs 'usefulness' on a
> continuum. I admire and encourage the core devs, in their pursuit of
> excellence. Asking 'what is the practical use case?' is essential. Not
> always is the answer complete.
>On the python unicode continuum version (3) is more useful than version
> (2). ( this is of course relative and debatable, so the statement is
> rhetorical ) The commitment and dedicated effort to move forward with a
> unicode default is not only commendable, but also admits to the 'usefulness'
> of same. Its not that version 2 was useless, its just that version 3 is so
> much more useful that people are 'using' it and dedicating their resources
> moving forward with python3.
>This is similar to the decimal module. Of course it had limited
> usefulness in version(2) thru 3.2/  but now, python3.3+ the decimal module
> is truly useful! Why? Glad you asked... because it is now fast enough for
> use cases previously reserved for floats. I found limited usefulness for
> decimal prior to 3.3, but now we're finding decimal so useful that some of
> us are wanting decimal to be the default. ( all of this is also relative and
> debatable )

So your definition of "useful" for the Decimal module is "fast" and
your definition of "useful" for Unicode is "mandated into use".
Neither of those is how any dictionary I know defines that word, and
you're not even consistent (since you said Unicode became useful at
3.0, which didn't - AFAIK - improve its performance any, while 3.3 did
(PEP 393)).

Here's one definition: "able to be used for a practical purpose or in
several ways". Does not say anything about performance. Python is
useful in that I am able to wield it to solve my problems. I don't
care that it's slower than C; in fact, a lot of the problems I solve
with Python are interactive, and run to completion faster than I can
notice them. If I use decimal.Decimal or fractions.Fraction in my
code, it is not because it's fast or slow or anything, it is because
that type matches what I want to do with it. Those types are useful to
me because there are situations in which they match my problem. While
I am interested in seeing a Decimal literal syntax in Python, and I
would support a shift to have "1.2" evaluate as a Decimal (but not
soon - it'd break backward compat *hugely*), I do not by any means
believe that Decimal will only become useful when it's the default
non-integer type in source code.

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

Re: Two Questions about Python on Windows

[Ian Kelly]

On Thu, Apr 3, 2014 at 2:15 PM, Mark Lawrence  wrote:
> On 03/04/2014 18:54, Ian Kelly wrote:
>>
>>
>> On Apr 3, 2014 11:12 AM, "Walter Hurry" > > wrote:
>>  >
>>  > Normally my Python development is done on FreeBSD and Linux. I know
>> that on *ix I simply have to make foo.py executable (the shebang line is
>> present, of course) to make it runnable.
>>  >
>>  > For my son's school assignment, I have to help him with Python for
>> Windows.
>>  >
>>  > As I understand it, on Windows a .py file is not executable, so I
>> need to run 'python foo py', or use a .pyw file.
>>  >
>>  > Question 1: Do I make a .pyw file simply by copying or renaming
>> foo.py to foo.pyw?
>>
>> Yes. The only distinction between .py and .pyw is that the Python
>> installer associates the former with Python.exe and the latter with
>> Pythonw.exe. Pythonw runs the script without creating a console window
>> for stdin/stdout.
>>
>
> Not with more modern versions of Python.
>
> c:\Users\Mark>assoc .py
> .py=Python.File
>
> c:\Users\Mark>ftype Python.File
> Python.File="C:\Windows\py.exe" "%1" %*

Which ultimately calls some version of python.exe.

> c:\Users\Mark>assoc .pyw
> .pyw=Python.NoConFile
>
> c:\Users\Mark>ftype Python.NoConFile
> Python.NoConFile="C:\Windows\pyw.exe" "%1" %*

Which ultimately calls some version of pythonw.exe.

I elided that detail because it wasn't relevant to the question at hand.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Examples of modern GUI python programms

[Sturla Molden]

Chris Angelico  wrote:

> Where? I can't see it. The home page redirects me to /news.html which
> doesn't say anything about GPL (other than in its collection of tags,
> which seem to be for finding other people's projects - that is,
> clicking that link takes you to a list of all pygame-using projects
> that are GPL'd); on the Documentation page, the license is clearly
> LGPL.
> 

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

"Pygame is free. Released under the GPL License, you can create open
source, free, freeware, shareware, and commercial games with it. See the
licence for full details."

But as pointed out, it seems to be a typo.

Sturla

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

Re: Yet Another Switch-Case Syntax Proposal

[Chris Angelico]

On Fri, Apr 4, 2014 at 5:12 AM, Ian Kelly  wrote:
> Use this instead:
>
> switch day case in ("Mon", "Tue", "Wed", "Thu", "Fri"):
> go_to_work = True
> day_type = "ferial"
> if day in ("Tue", "Thu"):
> lunch_time = datetime.time(11, 30)
> meeting_time = datetime.time(12, 30)
> else:
> lunch_time = datetime.time(12)
> meeting_time = datetime.time(14)
> case in ("Sat", "Sun"):
> go_to_work = False
> day_type = "festive"
>
> You get an extra level of indentation this way, but it reads less like
> spaghetti code.

Still not an ideal demonstration of fall-through. Here's a much more
useful form:

switch get("version") case 0:
commands_to_get_to_version_1
case 1:
commands_to_get_to_version_2
case 2:
commands_to_get_to_version_3

# Version 3 is current.
set("version", 3)
case 3:
break
else:
raise UnknownVersionError("Unexpected version!")

With fall-through, you don't need a loop around that. You jump to the
appropriate point and start executing code until you get to the bottom
(apart from the else, which obviously should never happen).

To implement this in current Python, I'd probably do all the
comparisons as inequalities:

v = get("version")
if v<0:
raise UnknownVersionError("Version is below zero!")
if v<1:
commands_to_get_to_version_1
if v<2:
commands_to_get_to_version_2

# Version 3 is current.
set("version", 3)
if v>3:
raise UnknownVersionError("Version is moving backward!")

Which means this isn't really a terribly compelling use-case; but I
think it's a better one than overlapping ranges. Fall-through in
C-like languages completely ignores the case labels on subsequent
sections, and executes them because of their position in the file; I'm
not sure how it's looking with the current proposals, but it seems the
case statements would have to be written to catch the values from
above.

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

Re: Unicode Chars in Windows Path

[Chris Angelico]

On Fri, Apr 4, 2014 at 5:41 AM, Terry Reedy  wrote:
> On 4/2/2014 11:10 PM, Chris Angelico wrote:
>>
>> On Thu, Apr 3, 2014 at 1:37 PM, Steven D'Aprano 
>> wrote:
>>>
>>> Windows accepts both forward and backslashes in file names.
>>
>>
>> Small clarification: The Windows *API* accepts both types of slash
>
>
> To me, that is what Steven said.

Yes, which is why I said "clarification" not "correction".

>> (you can open a file using forward slashes, for instance), but not all
>> Windows *applications* are aware of this (generally only
>> cross-platform ones take notice of this), and most Windows *users*
>> prefer backslashes.
>
>
> Do you have a source for that?

Hardly need one for the first point - it's proven by a single Windows
application that parses a path name by dividing it on backslashes.
Even if there isn't one today, I could simply write one, and prove my
own point trivially (albeit not usefully). Anything that simply passes
its arguments to an API (eg it just opens the file) won't need to take
notice of slash type, but otherwise, it's very *VERY* common for a
Windows program to assume that it can split paths manually.

The second point would be better sourced, yes, but all I can say is
that I've written programs that use and display slashes, and had
non-programmers express surprise at it; similarly when you see certain
programs that take one part of a path literally, and then build on it
with either type of slash, like zip and unzip - if you say "zip -r
C:\Foo\Bar", it'll tell you that it's archiving
C:\Foo\Bar/Quux/Asdf.txt and so on. Definitely inspires surprise in
non-programmers.

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

Re: Default mutable parameters in functions

[Ethan Furman]

On 04/03/2014 11:49 AM, fbick...@gmail.com wrote:


I put this into pythontutor.com's code visualization tool 
(http://goo.gl/XOmMjR) and it makes more sense what's going on.

I thought this was interesting; thought I would share.


That visualization tool is certainly neat, thanks!

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

Re: Default mutable parameters in functions

[Ian Kelly]

On Thu, Apr 3, 2014 at 12:49 PM,   wrote:
> Now call it with a value:
> foo([ 3 ])
>
> as you might expect:
> It's a parrot, not a cheese: [3]
>
> But now go back to no parameter in the call:
> foo()
> foo()
> foo()
>
> It's a parrot, not a cheese: [46]
> It's a parrot, not a cheese: [47]
> It's a parrot, not a cheese: [48]
>
> it picks up where it left off.
>
> I was rather expecting it to start with 4!

You haven't replaced the default value; you've only substituted a
different value for that call.  In this function:

def foo(x=3):
print(x)

You wouldn't expect a call of foo(27) to change the default value to
27, would you?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Test post via gmane.

[Dave Angel]

Terry Reedy  Wrote in message:
> On 4/3/2014 9:48 AM, Chris Angelico wrote:
>> On Thu, Apr 3, 2014 at 10:39 AM, Terry Reedy  wrote:
>>> Gmane has stopped receiving mail from the lists it mirrors at about 0:30 apr
>>> 2 (utc, I presume). I want to see what happens if I send to the list via
>>> gmane.
>>
>> Looks like Gmane has started transmitting after fourteen hours (at
>> least, that's what the timestamp on your post suggests). Is it now
>> receiving also?
> 
> Everything seems to be working now.
> 
> 

I have a separate problem that first happened when gmane started
 working again:  my nntp reader (Android nntp NewsReader)
 is
 showing extra posts in summary view that don't show in detail
 view. So there are apparently posts which are "new", but
 invisible. 


-- 
DaveA

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

Re: Two Questions about Python on Windows

[Mark Lawrence]

On 03/04/2014 18:54, Ian Kelly wrote:


On Apr 3, 2014 11:12 AM, "Walter Hurry" mailto:walterhu...@gmail.com>> wrote:
 >
 > Normally my Python development is done on FreeBSD and Linux. I know
that on *ix I simply have to make foo.py executable (the shebang line is
present, of course) to make it runnable.
 >
 > For my son's school assignment, I have to help him with Python for
Windows.
 >
 > As I understand it, on Windows a .py file is not executable, so I
need to run 'python foo py', or use a .pyw file.
 >
 > Question 1: Do I make a .pyw file simply by copying or renaming
foo.py to foo.pyw?

Yes. The only distinction between .py and .pyw is that the Python
installer associates the former with Python.exe and the latter with
Pythonw.exe. Pythonw runs the script without creating a console window
for stdin/stdout.



Not with more modern versions of Python.

c:\Users\Mark>assoc .py
.py=Python.File

c:\Users\Mark>ftype Python.File
Python.File="C:\Windows\py.exe" "%1" %*

c:\Users\Mark>assoc .pyw
.pyw=Python.NoConFile

c:\Users\Mark>ftype Python.NoConFile
Python.NoConFile="C:\Windows\pyw.exe" "%1" %*

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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Two Questions about Python on Windows

[Ethan Furman]

On 04/03/2014 10:54 AM, Ian Kelly wrote:

On Apr 3, 2014 11:12 AM, "Walter Hurry" wrote:


Secondly, on *ix, if there's an up-to-date .pyc in the right place and I run 
foo.py, Python will automagically use foo.pyc.


I don't believe this is exactly correct. Python will only use a .pyc 
automatically for imported modules. For a file
specified on the command line, Python won't try to second-guess the user as to 
which file they want.  The file could
have a .php extension, and Python will happily run it if the contents are valid 
Python code.


Right.  When specifying the file as a command-line argument to python, you have it include the extension, and that is 
exactly the file that python executes.  Also, using this method, a .pyc file is not created.  Only imported files may 
have a .py[co] file automatically created for corresponding .py file.


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

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

[Marko Rauhamaa]

Mark H Harris :

> computer science covers everything from a linked list to virtual
> reality, from cpu pipe lining to flash memory, from punched tape i/o
> to plasma displays--- to led back-lit flat panels.

From the point of view of computer science, those barely register. We
have had a revolution in hardware and software engineering, not computer
science.

> Computer science also includes theory, and most of what you mention
> actually had its beginnings in mathematics, not computer science. And
> yet, most of what you mention as fundamental to computer science is
> only the beginning.

Yes, but not much has taken place since in computer science. Even
virtualization was well covered before WWII from the scientific point of
view.

> Do we cease to work towards artificial intelligence? Do you believe
> that the AI work at MIT (using lisp) was a non step forwards for
> artificial intelligence; for computer science?

Little to write home about so far. Well, having Fritz beat the best
human chess players is impressive, to be sure. A testament to the power
of brute force. Similarly with Google and Big Data. But again, those are
not scientific advances.

> Did not David Hilbert get a kick-in-the-pants? You might have thought
> that mathematics at IAS would have folded its tents and blown away
> after Kurt Gődel proved (mostly as consequence of self-reference) that
> if an axiomatic system is complete it is also inconsistent, and if
> consistent assuredly incomplete! There are true statements which
> cannot be proven! Oh, crap. There must be systems of computation for
> which there is no proof, yet function non-the-less. Does this impact
> computer science today; does this impact AI studies today?

True, the mathematicians gave up on justifying their existence and went
back to counting beads. The foundational excitement still remains in
physics.

What does computer science have to show of late? A better mutual
exclusion algorithm? Dancing trees?

Ok, cryptography has been pretty exciting. The back and forth between
feasibility and unfeasibility. The ongoing cat and mouse.


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

Re: Yet Another Switch-Case Syntax Proposal

[Terry Reedy]

On 4/3/2014 12:02 PM, Lucas Malor wrote:


A more suitable place to propose this would be the python-ideas mailing list.


You're right. I posted here because this list was linked by PEP 1. But now that 
I read more there's also python-ideas listed. Let me know if I have to continue 
there instead.


Given that the idea has been posted to python-ideas and rejected, more 
that once I believe, I think this was the right place to post this to 
have variations discussed in a friendly manner.


--
Terry Jan Reedy

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

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

[Mark H Harris]

On 4/3/14 12:14 PM, Marko Rauhamaa wrote:

Mark H Harris :


So, python(3)'s use of unicode is exciting, not only as a step forward
for the python interpreter, but also as a leadership step forward in
computer science around the world.


Big words. I don't think computer science has experienced major steps
forward since the 1930's: combinatory logic, the Turing machine, the
Entscheidungsproblem, the halting problem,...

The one major latter-day addition is complexity theory (1960's).


hi Marko,  computer science covers everything from a linked list to 
virtual reality, from cpu pipe lining to flash memory, from punched tape 
i/o to plasma displays--- to led back-lit flat panels. Computer science 
also includes theory, and most of what you mention actually had its 
beginnings in mathematics, not computer science. And yet, most of what 
you mention as fundamental to computer science is only the beginning.


The Turning a-machines together (and parallel to) Alonzo Church's lambda 
calculus (diverse methodologies on computability) brought a negative 
answer on the Entscheidungsproblem; so much so that one might even think 
that artificial intelligence were impossible. Alan Turning proved 
(before computers ever existed) that one a-machine may not determine 
whether another a-machine configuration will loop or halt. So what? Do 
we cease to work towards artificial intelligence? Do you believe that 
the AI work at MIT (using lisp) was a non step forwards for artificial 
intelligence; for computer science?


Did not David Hilbert get a kick-in-the-pants? You might have thought 
that mathematics at IAS would have folded its tents and blown away after 
Kurt Gődel proved (mostly as consequence of self-reference) that if an 
axiomatic system is complete it is also inconsistent, and if consistent 
assuredly incomplete!  There are true statements which cannot be proven! 
 Oh, crap. There must be systems of computation for which there is no 
proof, yet function non-the-less. Does this impact computer science 
today; does this impact AI studies today?


We as human beings have only just begun. The human mind is a quantum 
computer. Can a bit be 1 and 0 at the same time??  It most certainly 
can; entanglement is a computational reality that we have only just 
begun to think about let alone comprehend, nor code for (whatever we 
might mean by that).


Mathematicians hate this, but, computers are the way forward for 
mathematics. Computer proofs are increasing; we are discovering that 
proofs of import are requiring computers and computation algorithms. We 
don't through our straight edges and compasses away; nor do we toss out 
our BIC pens and paper. Algorithm is what is needed because the 
mathematics is too complicated. Computer science is moving understanding 
forward with algorithm.


Beyond all of that is communication. That is where unicode comes in. 
Computer science is going to handle the problem of Universal 
Translation. Great strides have been taken towards this already. More 
are sure to come.


שלם

marcus

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

Default mutable parameters in functions

[fbicknel]

Hi all,

So I was reading about default values for functions and spied this:

Important warning: The default value is evaluated only once. This makes a 
difference when the default is a mutable object such as a list, dictionary, or 
instances of most classes. 

That's ok - guess I can get used to that.  So I did some experimenting and sure 
enough, immutables sort of behave "normally" in that they get the default value 
every time you call the function and don't specify the value for the parameter.

But mutables behave very strangely (imho).  Take this example:

def foo(bar=[ 42 ]):
print "It's a parrot, not a cheese: {value}".format(value=bar)
bar[0] += 1

Now call it like this:
foo()
foo()
foo()
foo()

and based on the "Important warning" above, you get something expected:
It's a parrot, not a cheese: [42]
It's a parrot, not a cheese: [43]
It's a parrot, not a cheese: [44]
It's a parrot, not a cheese: [45]

Now call it with a value:
foo([ 3 ])

as you might expect:
It's a parrot, not a cheese: [3]

But now go back to no parameter in the call:
foo()
foo()
foo()

It's a parrot, not a cheese: [46]
It's a parrot, not a cheese: [47]
It's a parrot, not a cheese: [48]

it picks up where it left off.

I was rather expecting it to start with 4!

I put this into pythontutor.com's code visualization tool 
(http://goo.gl/XOmMjR) and it makes more sense what's going on.

I thought this was interesting; thought I would share.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Yet Another Switch-Case Syntax Proposal

[Ethan Furman]

On 04/03/2014 09:02 AM, Lucas Malor wrote:


In reply to Ian Kelly:


Instead of disabling fallthrough by default, why not disable it all together?


I was tempted but there are cases in which it's useful. An example

switch day casein ("Monday", "Thursday", "Wednesday", "Tuesday", "Friday"):
 gotowork = True
 continue
casein ("Monday", "Thursday", "Wednesday", "Tuesday", "Friday"):
 daytype = "ferial"
casein ("Saturday", "Sunday")
 daytype = "festive"



Absolutely not.  Currently, the 'continue' key word means "stop processing and go back to the beginning".  You would 
have it mean "keep going forward".  Thus 'continue' would mean both "go backwards" and "go forwards" and would lead to 
unnecessary confusion.


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

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

[Rustom Mody]

On Thursday, April 3, 2014 10:44:16 PM UTC+5:30, Marko Rauhamaa wrote:
> Mark H Harris:

> > So, python(3)'s use of unicode is exciting, not only as a step forward
> > for the python interpreter, but also as a leadership step forward in
> > computer science around the world.

> Big words. I don't think computer science has experienced major steps
> forward since the 1930's: combinatory logic, the Turing machine, the
> Entscheidungsproblem, the halting problem,...

> The one major latter-day addition is complexity theory (1960's).

> Marko

Umm...
There is science and there is science
Those who think Einstein the greatest are not likely to consider Edison.

And vice versa :D
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unicode Chars in Windows Path

[Terry Reedy]

On 4/2/2014 11:10 PM, Chris Angelico wrote:

On Thu, Apr 3, 2014 at 1:37 PM, Steven D'Aprano  wrote:

Windows accepts both forward and backslashes in file names.


Small clarification: The Windows *API* accepts both types of slash


To me, that is what Steven said.


(you can open a file using forward slashes, for instance), but not all
Windows *applications* are aware of this (generally only
cross-platform ones take notice of this), and most Windows *users*
prefer backslashes.


Do you have a source for that?


So when you come to display a Windows path, you
may want to convert to backslashes. But that's for display.


--
Terry Jan Reedy

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

Re: Two Questions about Python on Windows

[Terry Reedy]

On 4/3/2014 1:06 PM, Walter Hurry wrote:

Normally my Python development is done on FreeBSD and Linux. I know that on *ix 
I simply have to make foo.py executable (the shebang line is present, of 
course) to make it runnable.

For my son's school assignment, I have to help him with Python for Windows.

As I understand it, on Windows a .py file is not executable, so I need to run 
'python foo py', or use a .pyw file.


If he edits the file with Idle (see Start menu Python directory, F5 runs 
the file and uses the Idle shell for input and output. When the program 
finishes, one can interactively examine objects and call functions. F5 
Run is like running a program from a console with -I.


--
Terry Jan Reedy

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

Re: Test post via gmane.

[Terry Reedy]

On 4/3/2014 9:48 AM, Chris Angelico wrote:

On Thu, Apr 3, 2014 at 10:39 AM, Terry Reedy  wrote:

Gmane has stopped receiving mail from the lists it mirrors at about 0:30 apr
2 (utc, I presume). I want to see what happens if I send to the list via
gmane.


Looks like Gmane has started transmitting after fourteen hours (at
least, that's what the timestamp on your post suggests). Is it now
receiving also?


Everything seems to be working now.

--
Terry Jan Reedy

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

Re: Yet Another Switch-Case Syntax Proposal

[Ian Kelly]

On Thu, Apr 3, 2014 at 10:02 AM, Lucas Malor <3kywjyd...@snkmail.com> wrote:
>> __contains__ is not part of the interface for iterables
>
> For what I know there's not an Iterable interface. For example List simply 
> extends Object. I hope that an ABC Iterable class will be introduced in a 
> future.

It already exists:

>>> import collections.abc
>>> isinstance([1,2,3], collections.abc.Iterable)
True

>> Instead of disabling fallthrough by default, why not disable it all together?
>
> I was tempted but there are cases in which it's useful. An example
>
> switch day casein ("Monday", "Thursday", "Wednesday", "Tuesday", "Friday"):
> gotowork = True
> continue
> casein ("Monday", "Thursday", "Wednesday", "Tuesday", "Friday"):
> daytype = "ferial"
> casein ("Saturday", "Sunday")
> daytype = "festive"

I don't see how it's useful there.  The first two cases are the same,
so just combine the code into one suite.  For overlapping cases where
the intersection needs to be handled by both suites, you can match
against the union and use conditionals to determine in more detail
which code to run.  For example, if you would write:

switch day case in ("Mon", "Wed", "Fri"):
lunch_time = datetime.time(12)
meeting_time = datetime.time(14)
continue
case in ("Tue", "Thu"):
lunch_time = datetime.time(11, 30)
meeting_time = datetime.time(12, 30)
continue
case in ("Mon", "Tue", "Wed", "Thu", "Fri"):
go_to_work = True
day_type = "ferial"
case in ("Sat", "Sun"):
go_to_work = False
day_type = "festive"

Use this instead:

switch day case in ("Mon", "Tue", "Wed", "Thu", "Fri"):
go_to_work = True
day_type = "ferial"
if day in ("Tue", "Thu"):
lunch_time = datetime.time(11, 30)
meeting_time = datetime.time(12, 30)
else:
lunch_time = datetime.time(12)
meeting_time = datetime.time(14)
case in ("Sat", "Sun"):
go_to_work = False
day_type = "festive"

You get an extra level of indentation this way, but it reads less like
spaghetti code.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Two Questions about Python on Windows

[Ian Kelly]

On Apr 3, 2014 11:12 AM, "Walter Hurry"  wrote:
>
> Normally my Python development is done on FreeBSD and Linux. I know that
on *ix I simply have to make foo.py executable (the shebang line is
present, of course) to make it runnable.
>
> For my son's school assignment, I have to help him with Python for
Windows.
>
> As I understand it, on Windows a .py file is not executable, so I need to
run 'python foo py', or use a .pyw file.
>
> Question 1: Do I make a .pyw file simply by copying or renaming foo.py to
foo.pyw?

Yes. The only distinction between .py and .pyw is that the Python installer
associates the former with Python.exe and the latter with Pythonw.exe.
Pythonw runs the script without creating a console window for stdin/stdout.

> Secondly, on *ix, if there's an up-to-date .pyc in the right place and I
run foo.py, Python will automagically use foo.pyc.

I don't believe this is exactly correct. Python will only use a .pyc
automatically for imported modules. For a file specified on the command
line, Python won't try to second-guess the user as to which file they
want.  The file could have a .php extension, and Python will happily run it
if the contents are valid Python code.

> Question 2: Does it work the same way on Windows, and does this apply
both to foo.py and foo.pyw?

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

Re:Retrieve item deep in dict tree?

[Yimr Zero]

Here is a tricky method :

reduce(lambda x,y:x[str(y)],keys,tree)



-- Forwarded message --
From: Roy Smith 
To: Python List 
Cc:
Date: Wed, 2 Apr 2014 13:58:16 -0400
Subject: Retrieve item deep in dict tree?
I have a big hairy data structure which is a tree of nested dicts.  I have
a sequence of strings which represents a path through the tree.  Different
leaves in the tree will be at different depths (which range from 1 to about
4 or 5 at most).  I want to get the value stored at that path.  Thus, if

keys = ['foo', 'bar', 'baz']

I want to retrieve tree['foo']['bar']['baz'].

Is there some idiomatic, non-cryptic way to write that as a one-liner?

I'm using Python 2.7.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Two Questions about Python on Windows

[maxerickson]

On Thursday, April 3, 2014 1:06:29 PM UTC-4, Walter Hurry wrote:
> Normally my Python development is done on FreeBSD and Linux. I know that on 
> *ix I simply have to make foo.py executable (the shebang line is present, of 
> course) to make it runnable.
> 
> For my son's school assignment, I have to help him with Python for Windows.
> 
> As I understand it, on Windows a .py file is not executable, so I need to run 
> 'python foo py', or use a .pyw file.
> 
> Question 1: Do I make a .pyw file simply by copying or renaming foo.py to 
> foo.pyw?
> 
> Secondly, on *ix, if there's an up-to-date .pyc in the right place and I run 
> foo.py, Python will automagically use foo.pyc.
>  
> Question 2: Does it work the same way on Windows, and does this apply both to 
> >foo.py and foo.pyw?

The compile caching is more or less the same. It works transparently.

If you are working in a cmd shell, it doesn't matter what extension you use, 
pyw just allows for associating scripts with an interpreter stub that does not 
bring up a shell (for a gui or whatever). Console and gui programs are handled 
separately on Windows and that's how Python makes the option available to 
scripts.

You can also edit the PATHEXT environment variable to include .py/.pyw, making 
the python source files executable (as long as the types are properly 
registered with Windows; if double clicking runs them they should be properly 
registered).


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

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

[Marko Rauhamaa]

Mark H Harris :

> So, python(3)'s use of unicode is exciting, not only as a step forward
> for the python interpreter, but also as a leadership step forward in
> computer science around the world.

Big words. I don't think computer science has experienced major steps
forward since the 1930's: combinatory logic, the Turing machine, the
Entscheidungsproblem, the halting problem,...

The one major latter-day addition is complexity theory (1960's).


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

Two Questions about Python on Windows

[Walter Hurry]

Normally my Python development is done on FreeBSD and Linux. I know that on *ix 
I simply have to make foo.py executable (the shebang line is present, of 
course) to make it runnable.

For my son's school assignment, I have to help him with Python for Windows.

As I understand it, on Windows a .py file is not executable, so I need to run 
'python foo py', or use a .pyw file.

Question 1: Do I make a .pyw file simply by copying or renaming foo.py to 
foo.pyw?

Secondly, on *ix, if there's an up-to-date .pyc in the right place and I run 
foo.py, Python will automagically use foo.pyc.

Question 2: Does it work the same way on Windows, and does this apply both to 
foo.py and foo.pyw? 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

[Mark H Harris]

On 4/1/14 5:33 PM, Terry Reedy wrote:

   hi Terry, hope you are well today, despite gmane difficulties;


If you narrowly meant "The python interpreter only starting using
unicode as the default text class in 3.0", then you are, in that narrow
sense, correct.


   Yes. When I speak of 'python' I am almost always speaking about the 
interpreter. If I speak of the python community, and I rarely do, I 
explicitly use the word 'community'. I am concerned with backward 
compatibility in my own stuff, but I am primarily interested in python3, 
and I have made the conscious decision to use only python3 moving 
forward, except in those cases (like QPython 2.7.2 on the Android 
platform ). So, python(3)'s use of unicode is exciting, not only as a 
step forward for the python interpreter, but also as a leadership step 
forward in computer science around the world.



 I didn't ask when it was introduced, I asked when it became useful?


It was useful immediately when introduced. Do you really think we would
add something useless, and that no one wanted to use?  Core developers
constantly ask 'What is the practical use case?' in response to
suggested additions.


   'Useful' must always be taken in context, and also contextually 
evaluated with an on-going methodology which constantly informs 
'usefulness' on a continuum. I admire and encourage the core devs, in 
their pursuit of excellence. Asking 'what is the practical use case?' is 
essential. Not always is the answer complete.
   On the python unicode continuum version (3) is more useful than 
version (2). ( this is of course relative and debatable, so the 
statement is rhetorical ) The commitment and dedicated effort to move 
forward with a unicode default is not only commendable, but also admits 
to the 'usefulness' of same. Its not that version 2 was useless, its 
just that version 3 is so much more useful that people are 'using' it 
and dedicating their resources moving forward with python3.
   This is similar to the decimal module. Of course it had limited 
usefulness in version(2) thru 3.2/  but now, python3.3+ the decimal 
module is truly useful! Why? Glad you asked... because it is now fast 
enough for use cases previously reserved for floats. I found limited 
usefulness for decimal prior to 3.3, but now we're finding decimal so 
useful that some of us are wanting decimal to be the default. ( all of 
this is also relative and debatable )



Fine. You asked 'When did unicode in Python become useful.'
Answer: 2.0, not 3.0. Most unicode use in Python is still running on
Python 2. It works well enough that people are reluctant to migrate
working and tested production code. End of discussion?


   Sure. Yes, this is sad. Python2 works. Python2 is inconsistent, and 
troublesome. ( I do not mean that to be insulting, not in the least, its 
just true )
   I've been studying python3 now for several years; cross referencing 
between python2 and python3 has been fun and illuminating, from a 
practical programming standpoint as well as from a standpoint of general 
interest in computer science, and the science of language design. Its 
been a magnificent journey for me (thanks to all of you who provided the 
food for thought, as it were )
   Python3 is not perfect; but python3 is *way* more consistent than 
python2 and consequently *way* more useful than python2. ( this is 
relative, debatable, or even certainly one of those discussions of 
personal preference and taste perhaps ) As we move forward with use 
cases we grow and consequently our language evolves. This is true of the 
spoken word, also true of the comp sci word. In this sense, at this 
time, I would call python2 a 'mess'. Python3 straightened up the 'mess' 
pep after pep.  At what point does do we arrive at 'elegant'?  Beats me.
Maybe when number is unified, decimal is default, scientists are free to 
mix literals of all types in a convenient and intelligent way. But, for 
the moment, python3 is elegant---and very useful.  No doubt Python4 will 
build upon that; perhaps we will come to think of python3 as a mess?



I hear, speak, read, and write standard American English.



   ~nice.   Trouble is, as we've stated before, most of our comm in 
life is non verbal.  So, even in the best (E)scale effectiveness we are 
at a loss because mailing lists and news servers lose the non verbals, 
the smiles, and shrugs, the waves, and the handshakes. rats()


Enjoy your day Terry.


PS   I just thought of another example along the lines of continual 
usefulness: IDLE. (you've worked on IDLE, right?) IDLE is now useful ! 
---a few years back, not so much.  That is not to say that IDLE was 
*never* useful back in the day (it always has been, to some extent), but 
since it has matured over the years it is at a point now where it really 
can be the default (very useful) development interface for code and 
test. Its now stable, does what it advertises, and provides a clean 
simple environment that is pleasant to work w

Re: Yet Another Switch-Case Syntax Proposal

[Lucas Malor]

Thank you for reading and commenting my proposal. Here are my replies:

In reply to Chris Angelico:

> I don't like the "iterable vs non-iterable" distinction. Compare: [...]
> case "Test": # And there's your problem.

Yes, I had already thought after I posted that testing against string it's a 
problem. But I think that the more practical and unambiguous solution is to 
introduce also "casein" as a new keyword. So if you want to test a string:

switch mystring case "-h":
print_usage()
case "--version"
print_version()

If you want to test against membership:

switch mychar casein "aeiou":
mychar.vocal = True

I prefer "casein" instead of "case in" for the same reason Python uses "elif" 
instead of "else if".



In reply to Ian Kelly:

> A more suitable place to propose this would be the python-ideas mailing list.

You're right. I posted here because this list was linked by PEP 1. But now that 
I read more there's also python-ideas listed. Let me know if I have to continue 
there instead.

> Why just just an identifier after the switch keyword instead of an expression?

Because I wronged, it can be an expression_list as well.

> An expression_list is one or more independent expressions separated by commas 
> that 
> don't create a tuple.

Well, py docs state "An expression list containing at least one comma yields a 
tuple".

> __contains__ is not part of the interface for iterables

For what I know there's not an Iterable interface. For example List simply 
extends Object. I hope that an ABC Iterable class will be introduced in a 
future. 
Anyway, I think that "switch x casein y" should simply raise a TypeError if y 
doesn't implement __contains__, like "x in y" do.

> If we overload the continue keyword in this way, then a continue can't be 
> used within the switch
> to control a loop that the switch is nested within.

Well, this is the same problem for, say, a for loop nested inside another for 
loop, and you can solve it with the same methods.

> Instead of disabling fallthrough by default, why not disable it all together?

I was tempted but there are cases in which it's useful. An example

switch day casein ("Monday", "Thursday", "Wednesday", "Tuesday", "Friday"):
gotowork = True
continue
casein ("Monday", "Thursday", "Wednesday", "Tuesday", "Friday"):
daytype = "ferial"
casein ("Saturday", "Sunday")
daytype = "festive"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Examples of modern GUI python programms

[Sturla Molden]

On 03/04/14 16:02, Robert Kern wrote:


Kivy depends on PyGame which is GPL, and can only be used to build GPL
software.


It is not.

http://www.pygame.org/LGPL


Their web paged says GPL, but I assume that is an error.

Is Python allowed on iOS anyway? Apple used to ban any code not written 
in C, C++, Objective-C and Objective-C++.



Sturla

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

Re: Examples of modern GUI python programms

[Chris Angelico]

On Fri, Apr 4, 2014 at 1:00 AM, Fabio Zadrozny  wrote:
> Actually, PyGame is LGPL: http://www.pygame.org/LGPL (it's also what their
> source files say, although I noted that in their homepage the link which
> points to http://www.pygame.org/LGPL *wrongly* says GPL when the actual link
> goes to LGPL and the sources say LGPL).

Where? I can't see it. The home page redirects me to /news.html which
doesn't say anything about GPL (other than in its collection of tags,
which seem to be for finding other people's projects - that is,
clicking that link takes you to a list of all pygame-using projects
that are GPL'd); on the Documentation page, the license is clearly
LGPL.

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

Re: Unicode Chars in Windows Path

[Chris Angelico]

On Fri, Apr 4, 2014 at 12:57 AM,   wrote:
> An argument [in a position where a list of filenames is expected] with *
> or ? in it _always_ gets globbed, so "C:\dir with spaces\*.txt" can be
> used. This is part of the reason the program is responsible for globbing
> rather than the shell - because only the program knows if it expects a
> list of filenames in that position vs a text string for some other
> purpose.

Which, I might mention, is part of why the old DOS way (still
applicable under Windows, but I first met it with MS-DOS) of searching
for files was more convenient than it can be with Unix tools. Compare:

-- Get info on all .pyc files in a directory --
C:\>dir some_directory\*.pyc
$ ls -l some_directory/*.pyc

So far, so good.

-- Get info on all .pyc files in a directory and all its subdirectories --
C:\>dir some_directory\*.pyc /s
$ ls -l `find some_directory -name \*.pyc`

Except that the ls version there can't handle names with spaces in
them, so you need to faff around with null termination and stuff. With
bash, you can use 'shopt -s globstar; ls -l **/*.py', but that's not a
default-active option (at least, it's not active on any of the systems
I use, but they're all Debians and Ubuntus; it might be active by
default on others), and I suspect a lot of people don't even know it
exists; I know of it, but don't always think of it, and often end up
doing the above flawed version.

On the flip side, having the shell handle it does mean you
automatically get this on *any* command. You can go and delete all
those .pyc files by just changing "ls -l" into "rm" or "dir" into
"del", but that's only because del happens to support /s; other DOS
programs may well not.

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

Re: Unicode Chars in Windows Path

[Peter Otten]

Marko Rauhamaa wrote:

> Chris Angelico :
> 
>> Small clarification: The Windows *API* accepts both types of slash
>> (you can open a file using forward slashes, for instance), but not all
>> Windows *applications* are aware of this (generally only
>> cross-platform ones take notice of this), and most Windows *users*
>> prefer backslashes. So when you come to display a Windows path, you
>> may want to convert to backslashes. But that's for display.
> 
> Didn't know that. More importantly, I had thought forward slashes were
> valid file basename characters, but Windows is surprisingly strict about
> that:
> 
>< > : " / \ | ? * NUL
> 
> are not allowed in basenames. Unix/linux disallows only:
> 
>   / NUL
> 
> In fact, proper dealing with punctuation in pathnames is one of the main
> reasons to migrate to Python from bash. Even if it is often possible to
> write bash scripts that handle arbitrary pathnames correctly, few script
> writers are pedantic enough to do it properly. For example, newlines in
> filenames are bound to confuse 99.9% of bash scripts.

That doesn't bother me much as 99.8% of all bash scripts are already 
confused by ordinary space chars ;)

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

Re: Examples of modern GUI python programms

[Fabio Zadrozny]

On Wed, Apr 2, 2014 at 8:52 AM, Sturla Molden wrote:

> Wolfgang Keller  wrote:
>
> > Judging from the example screenshots on their website, Kivy might be
> > adequate.
>
> Kivy depends on PyGame which is GPL, and can only be used to build GPL
> software.


Actually, PyGame is LGPL: http://www.pygame.org/LGPL (it's also what their
source files say, although I noted that in their homepage the link which
points to http://www.pygame.org/LGPL *wrongly* says GPL when the actual
link goes to LGPL and the sources say LGPL).

Cheers,

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

Re: Examples of modern GUI python programms

[Robert Kern]

On 2014-04-02 12:52, Sturla Molden wrote:

Wolfgang Keller  wrote:


Judging from the example screenshots on their website, Kivy might be
adequate.


Kivy depends on PyGame which is GPL, and can only be used to build GPL
software.


It is not.

http://www.pygame.org/LGPL

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: python nose unit test - test plan preparation

[Mark Lawrence]

On 03/04/2014 03:02, Rustom Mody wrote:

On Wednesday, April 2, 2014 6:52:04 PM UTC+5:30, Hareesha Karunakar wrote:

Hello Group,
I am using python's nose testing frame work for my automated testing.
I would like to run my python cases and generate only the documentation without 
actually running/executing the cases.



How is this possible?
I head "collect-only" plugin will help to achieve the same. But I think I could 
not make out how to use this effectively?
Are there any other possibilities?
I mainly want to collect the "comments" form the test classes and test methods.


If you dont get answers here you can try the nose group
https://groups.google.com/forum/#!forum/nose-users



Or see http://lists.idyll.org/listinfo/testing-in-python which is also 
available as gmane.comp.python.testing.general


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Unicode Chars in Windows Path

[random832]

On Thu, Apr 3, 2014, at 5:00, Marko Rauhamaa wrote:
> In fact, proper dealing with punctuation in pathnames is one of the main
> reasons to migrate to Python from bash. Even if it is often possible to
> write bash scripts that handle arbitrary pathnames correctly, few script
> writers are pedantic enough to do it properly. For example, newlines in
> filenames are bound to confuse 99.9% of bash scripts.

Incidentally, these rules mean there are different norms about how
command line arguments are parsed on windows. Since * and ? are not
allowed in filenames, you don't have to care whether they were quoted.
An argument [in a position where a list of filenames is expected] with *
or ? in it _always_ gets globbed, so "C:\dir with spaces\*.txt" can be
used. This is part of the reason the program is responsible for globbing
rather than the shell - because only the program knows if it expects a
list of filenames in that position vs a text string for some other
purpose.

This is unfortunate, because it means that most python programs do not
handle filename patterns at all (expecting the shell to do it for them)
- it would be nice if there was a cross-platform way to do this.

Native windows wildcards are also weird in a number of ways not emulated
by the glob module. Most of these are not expected by users, but some
users may expect, for example, *.htm to match files ending in .html; *.*
to match files with no dot in them, and *. to match _only_ files with no
dot in them. The latter two are guaranteed by the windows API, the first
is merely common due to default shortname settings. Also, native windows
wildcards do not support [character classes].
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compact way to assign values by slicing list in Python

[Marco Buttu]

On 04/02/2014 01:17 AM, Mark Lawrence wrote:

Came across this
http://stackoverflow.com/questions/22756632/compact-way-to-assign-values-by-slicing-list-in-python?newsletter=1&nlcode=245176|202f
- just curious what you guys and gals thought of the answers.


I prefere this one:

bar = ['a','b','c','x','y','z']
v1, _, _, v2, v3, _ = bar

I also like the solution with itemgetter:

v1, v2, v3 = itemgetter(0, 3, 4)(bar)

but I think it is less readable than the previous one

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

Re: Test post via gmane.

[Chris Angelico]

On Thu, Apr 3, 2014 at 10:39 AM, Terry Reedy  wrote:
> Gmane has stopped receiving mail from the lists it mirrors at about 0:30 apr
> 2 (utc, I presume). I want to see what happens if I send to the list via
> gmane.

Looks like Gmane has started transmitting after fourteen hours (at
least, that's what the timestamp on your post suggests). Is it now
receiving also?

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

Re: Examples of modern GUI python programms

[Sturla Molden]

Wolfgang Keller  wrote:

> Judging from the example screenshots on their website, Kivy might be
> adequate.

Kivy depends on PyGame which is GPL, and can only be used to build GPL
software.

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

Re: Calculating time differences given daylight savings time

[Chris “Kwpolska” Warrick]

On Thu, Apr 3, 2014 at 3:45 AM, Washington Ratso  wrote:
> I am running Python 2.7 and would like to be able to calculate to the second 
> the time difference between now and some future date/time in the same 
> timezone while taking into account daylight savings time.  I do not have 
> pytz.  Any ideas how to do it?
>
> If it requires having pytz, how would I do it with pytz?
>
> Thank you.
> --
> https://mail.python.org/mailman/listinfo/python-list

It requires having pytz, or dateutil, in order to get timezone
objects*.  You can also create those objects yourself, but that’s
tricky — and you SHOULD NOT do time zones on your own and just use
something else.  Why?  See [0].

Example with pytz:

# Necessary imports
import pytz
from datetime import datetime

# the timezone in this example is Europe/Warsaw — use your favorite one
tz = pytz.timezone('Europe/Warsaw')

now = datetime.now(tz)
# Note I’m not using the tzinfo= argument of datetime(), it’s flaky
and seemingly uses a historic WMT (+01:24) timezone that is dead since
1915.
future = tz.localize(datetime(2014, 12, 24))

# And now you can happily do:

delta = future - now

# and you will get the usual timedelta object, which you can use the usual way.


###

* pytz ships the Olson tz database, while dateutil maps uses your
system’s copy of the tz database (if you are on Linux, OS X or
anything else that is not Windows, really) or maps to the Windows
registry.  Use whichever suits you.

[0]: http://www.youtube.com/watch?v=-5wpm-gesOY

-- 
Chris “Kwpolska” Warrick 
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense
-- 
https://mail.python.org/mailman/listinfo/python-list

Test post via gmane.

[Terry Reedy]

Gmane has stopped receiving mail from the lists it mirrors at about 0:30 
apr 2 (utc, I presume). I want to see what happens if I send to the list 
via gmane.



--
Terry Jan Reedy

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

Re: Examples of modern GUI python programms

[Sturla Molden]

Wolfgang Keller  wrote:
>> Id like to ask.. do you know any modern looking GUI examples of

> Judging from the example screenshots on their website, Kivy might be
> adequate.

If you want to build something from scratch, libSDL is excellent and free
(zlib license). Official supported platforms are:

Windows XP/Vista/7/8
Mac OS X 10.5+
Linux 2.6+
iOS 5.1.1+
Android 2.3.3+

libSDL can be used from Python using ctypes or Cython. 

There is no GUI, but you can draw whatever you like.


Sturla

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

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

[Terry Reedy]

On 4/1/2014 5:26 PM, Mark H Harris wrote:


 I didn't really start using unicode
until about 5 years ago; python has only really used it since python3.
right?


If you narrowly meant "The python interpreter only starting using 
unicode as the default text class in 3.0", then you are, in that narrow 
sense, correct. If you meant something broader, if by 'python' you meant 
'the python community' or 'python programmers', then you are wrong.



 No. Python 2.2 introduced Unicode.


2.0, as someone else corrected.


 I didn't ask when it was introduced, I asked when it became useful?


It was useful immediately when introduced. Do you really think we would 
add something useless, and that no one wanted to use?  Core developers 
constantly ask 'What is the practical use case?' in response to 
suggested additions.


For either question, your original answer is wrong.


No you didn't.


Does not matter. The answer he gave to the question he claims he asked, 
and the elaboration below, is wrong.



Yes, I did.


Fine. You asked 'When did unicode in Python become useful.'
Answer: 2.0, not 3.0. Most unicode use in Python is still running on 
Python 2. It works well enough that people are reluctant to migrate 
working and tested production code. End of discussion?


> Our common English is apparently getting in the way.

Well, I speak American English, and you don't, apparently; U.K.?


I hear, speak, read, and write standard American English.

--
Terry Jan Reedy

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

Gauteng Usergroup Meeting

[Frank Millman]

A meeting of python users in Gauteng, South Africa has been arranged for 
Saturday 12th April.

Full discussion and details can be found here -

https://groups.google.com/forum/#!topic/gpugsa/qZEy-ptVxac

I was not aware of this group until recently, even though I live in Gauteng, 
so I thought I would mention it here in case others are equally unaware.

Frank Millman



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

Compact way to assign values by slicing list in Python

[Mark Lawrence]

Came across this 
http://stackoverflow.com/questions/22756632/compact-way-to-assign-values-by-slicing-list-in-python?newsletter=1&nlcode=245176|202f 
- just curious what you guys and gals thought of the answers.


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Unicode Chars in Windows Path

[Marko Rauhamaa]

Chris Angelico :

> Small clarification: The Windows *API* accepts both types of slash
> (you can open a file using forward slashes, for instance), but not all
> Windows *applications* are aware of this (generally only
> cross-platform ones take notice of this), and most Windows *users*
> prefer backslashes. So when you come to display a Windows path, you
> may want to convert to backslashes. But that's for display.

Didn't know that. More importantly, I had thought forward slashes were
valid file basename characters, but Windows is surprisingly strict about
that:

   < > : " / \ | ? * NUL

are not allowed in basenames. Unix/linux disallows only:

  / NUL

In fact, proper dealing with punctuation in pathnames is one of the main
reasons to migrate to Python from bash. Even if it is often possible to
write bash scripts that handle arbitrary pathnames correctly, few script
writers are pedantic enough to do it properly. For example, newlines in
filenames are bound to confuse 99.9% of bash scripts.


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

Re: Unicode Chars in Windows Path

[alister]

On Wed, 02 Apr 2014 16:27:04 -0700, Steve wrote:

> Hi All,
> 
> I'm in need of some encoding/decoding help for a situation for a Windows
> Path that contains Unicode characters in it.
> 
>  CODE 
> 
> import os.path import codecs import sys
> 
> All_Tests =
> [u"c:\automation_common\Python\TestCases\list_dir_script.txt"]
> 
> 
> for curr_test in All_Tests:
>   print("\n raw : " + repr(curr_test) + "\n")
>   print("\n encode : %s \n\n" ) % 
>   os.path.normpath(codecs.encode(curr_test, "ascii"))
>   print("\n decode : %s \n\n" ) %  curr_test.decode('string_escape')
> 
>  CODE 
> 
> 
> Screen Output :
> 
>  raw : u'c:\x07utomation_common\\Python\\TestCases\\list_dir_script.txt'
> 
>  encode : c:utomation_common\Python\TestCases\list_dir_script.txt
> 
>  decode : c:utomation_common\Python\TestCases\list_dir_script.txt
> 
> 
> My goal is to have the properly formatting path in the output :
> 
> 
> c:\automation_common\Python\TestCases\list_dir_script.txt
> 
> 
> What is the "magic" encode/decode sequence here??
> 
> Thanks!
> 
> Steve

you have imported os.path you will find it contains a number of functions 
to make this task easier*

import os.path
root=os.path.sep
drive='c:'
path= [root,
'automation_common','python',
'TestCases','list_dir_script.txt']
all_tests=os.path.join(drive,*path)

works happily even in linux (the un-necessary drive letter simply gets 
stripped)

*easier to maintain cross platform compatibility
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Retrieve item deep in dict tree?

[Ian Kelly]

On Wed, Apr 2, 2014 at 10:15 PM, Rustom Mody  wrote:
> On Thursday, April 3, 2014 8:11:33 AM UTC+5:30, Rustom Mody wrote:
>> On Wednesday, April 2, 2014 11:28:16 PM UTC+5:30, Roy Smith wrote:
>> > I have a big hairy data structure which is a tree of nested dicts.  I have 
>> > a sequence of strings which represents a path through the tree.  Different 
>> > leaves in the tree will be at different depths (which range from 1 to 
>> > about 4 or 5 at most).  I want to get the value stored at that path.  
>> > Thus, if
>
>> > keys = ['foo', 'bar', 'baz']
>
>> > I want to retrieve tree['foo']['bar']['baz'].
>
>> > Is there some idiomatic, non-cryptic way to write that as a one-liner?
>
>> > I'm using Python 2.7.
>
>> What you are asking for is probably:
>
>>  >>> reduce((lambda tr, att: tr[att]), ['a','b','c'], nested)
>> 'Hiii!!'
>
> Shorter version:
>
reduce(dict.get, ['a','b','c'], nested)
> 'Hiii!!'

That breaks if the dicts are ever replaced with an alternate mapping
implementation (or a dict subclass that overrides the get method), and
incorrectly returns None instead of raising KeyError if the last key
in the sequence does not exist (and if any of the other keys don't
exist, you'll get a TypeError instead of a KeyError). This is more
robust:

import operator
reduce(operator.getitem, ['a', 'b', 'c'], nested)
-- 
https://mail.python.org/mailman/listinfo/python-list