Re: Why do Perl programmers make more money than Python programmers

[88888 Dihedral]

Chris Angelico於 2013年5月7日星期二UTC+8下午9時32分55秒寫道：
> On Tue, May 7, 2013 at 11:22 PM, jmfauth  wrote:
> 
> > There are plenty of good reasons to use Python. There are
> 
> > also plenty of good reasons to not use (or now to drop)
> 
> > Python and to realize that if you wish to process text
> 
> > seriously, you are better served by using "corporate
> 
> > products" or tools using Unicode properly.
> 
> 
> 
> There are plenty of good reasons to use Python. One of them is the
> 
> laughs you can get any time jmf posts here. There are also plenty of
> 
> good reasons to drop Python. One of them is because corporate products
> 
> like Microsoft Visual Studio are inherently better specifically
> 
> because they cost you money, and there's no way that something you
> 
> paid nothing for can ever be as good as that. Plus, you get to write
> 
People used MS products  because most bosses did not  want to pay 
the prices of work stations,  the minis, or the main-frames and 
the salaries of the system  administrators  in 199x. 


> code that works on only one platform, and that's really good. Finally,
> 
> moving off Python would mean you don't feel obliged to respond to jmf,
> 
> which will increase your productivity measurably.
> 
> 
> 
> ChrisA

The price issue of a software  package or a platform is not 
the only  way to judge a programming language.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Append to python List

[88888 Dihedral]

Jussi Piitulainen於 2013年5月9日星期四UTC+8下午2時55分20秒寫道：
> RAHUL RAJ writes:
> 
> 
> 
> > Checkout the following code:
> 
> > 
> 
> > sample2 = [x+y for x in range(1,10) for y in range(1,10) if x!=y]   
> 
> > output=[]
> 
> > output=[x for x in sample2 if x not in output]
> 
> > 
> 
> > the output I get is
> 
> > 3 4 5 6 7 8 9 10 3 5 6 7 8 9 10 11 4 5 7 8 9 10 11 12 5 6 7 9 10 11
> 
> > 12 13 6 7 8 9 11 12 13 14 7 8 9 10 11 13 14 15 8 9 10 11 12 13 15 16
> 
> > 9 10 11 12 13 14 15 17 10 11 12 13 14 15 16 17
> 
> > 
> 
> > which contains duplicate values.
> 
> 
> 
> The second comprehension, [x for x in sample2 if x not in output], in
> 
> the context, is equivalent to [x for x in sample2 if x not in []]. It
> 
> does not refer to an incomplete version of the list that gets assigned
> 
> to the variable after it's done.

This is just the handy style for a non-critical loop.
In a critical loop, the number of  the total operation counts
does matter in the execution speed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Append to python List

[88888 Dihedral]

Jussi Piitulainen於 2013年5月9日星期四UTC+8下午7時30分05秒寫道：
> 88888 Dihedral writes:
> 
> 
> 
> > This is just the handy style for a non-critical loop.
> 
> > In a critical loop, the number of  the total operation counts
> 
> > does matter in the execution speed.


> 
> 
> 
> Do you use speed often?

There is another concern about the list construction part
in programming.

Although a typical PC is installed with gaga bytes of DRAM
now,  anything that will use more memory from the heap
dynamically could fail in the run time.

It is the programmer's job to identify this kind of sources
in minds.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Append to python List

[88888 Dihedral]

Chris Angelico於 2013年5月12日星期日UTC+8上午12時00分44秒寫道：
> On Sun, May 12, 2013 at 1:47 AM, Anssi Saari  wrote:
> 
> > Chris Angelico  writes:
> 
> >
> 
> >> On Thu, May 9, 2013 at 9:30 PM, Jussi Piitulainen
> 
> >>  wrote:
> 
> >>> 8 Dihedral writes:
> 
> >>>
> 
> >>>> This is just the handy style for a non-critical loop.
> 
> >>>> In a critical loop, the number of  the total operation counts
> 
> >>>> does matter in the execution speed.
> 
> >>>
> 
> >>> Do you use speed often?
> 
> >>
> 
> >> Dihedral is a bot. Quite a good one, but a bot.
> 
> >
> 
> > That's been said often enough. Is the source available and is it in
> 
> > Python?
> 
> 
> 
> Not to my knowledge. Technically Dihedral is merely _rumoured_ to be a
> 
> bot, as we have no actual proof; but we've been conducting a variety
> 
> of Turing tests via this list and have yet to see any strong argument
> 
> for his being deemed human. Most humans would get defensive, or at
> 
> least protest, if treated as bots; Dihedral never has, despite being
> 
> referred to in this way a number of times.
> 
> 
> 
> ChrisA

Don't you get the practices of   POSIX ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's sad, unimaginative Enum

[88888 Dihedral]

Chris Angelico於 2013年5月14日星期二UTC+8上午1時36分34秒寫道：
> On Mon, May 13, 2013 at 8:17 PM, Steven D'Aprano
> 
>  wrote:
> 
> > Let's look at his major criticisms:
> 
> >
> 
> > 1) values aren't automatically generated.
> 
> >
> 
> > True. So what? That is the *least* important part of enums.
> 
> 
> 
> I stopped following the -ideas threads about enums, but IIRC
> 
> autogeneration of values was in quite a few of the specs early on. So
> 
> you can probably find the arguments against it in the list archives.
> 
> 
> 
> FWIW, though, I do like C's autogeneration of enum values - but use it
> 
> in only a small proportion of my enums. It's not a terrible loss, but
> 
> it is a loss.
> 
> 
> 
> ChrisA

Because a hash table can replace the enums in other languages,
it is more pythonic to use a dictionary built first
to replace the enums.

I think it is the same style of programming  in perl and ruby.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python C-API: how to define nested classes?

[88888 Dihedral]

Serge WEINSTOCK於 2013年5月16日星期四UTC+8下午4時55分07秒寫道：
> Hi,
> 
>  
> 
> I'm currently writing a C extension module for python using the "raw" C-API. 
> I would like to be able to define "nested classes" like in the following 
> python code
> 
>  
> 
> 
> 
> class A:
> 
>     class B:
> 
>     def __init__(self):
> 
>     self.i = 2
> 
>     def __init__(self):
> 
>     self.b = A.B()
> 
> a = A()
> 
> b = A.B()
> 
> print(a.b.i)
> 
> print(b.i)
> 
> 
> 
>  
> 
> How can I create such nested class with the C-API?
> 
>  
> 
> Serge WEINSTOCK
> 
>  
> 
> 
> 
> 
> ___
> 
> This e-mail may contain confidential and/or privileged information. If you 
> are not the intended recipient (or have received this e-mail in error) please 
> notify the sender immediately and delete this e-mail. Any unauthorised 
> copying, disclosure or distribution of the material in this e-mail is 
> prohibited.
> 
> 
> Please refer to http://www.bnpparibas.co.uk/en/email-disclaimer/ for 
> additional disclosures.

The nested class is just defining the scope of the nested 
class object that can be  used solely in all outer proper 
classes.

It is not very useful in a language which supports 
dynamical run-time attribute binding in the instance level.

in the outer 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Back-end Python Developer Seeking Telecommute Work

[88888 Dihedral]

Rob Sutton於 2013年5月18日星期六UTC+8上午2時36分07秒寫道：
> I am seeking part/full time work as a back-end Python developer (telecommute 
> or Utah only).  I have been maintaining a 
> Debian/Python/Django/Apache/PostgreSQL/PHP/MySql web application for 3 years 
> on my own.  I do all the development, database and system management myself. 
> I can setup a complete system from scratch remotely or setup the hosting 
> service.  I have experience with Virtualbox and ProxMox virtualization.  I 
> have expereince in all areas of IT including telecom, programming, 
> networking, hardware and software.  Worked with Retail stores, warehousing 
> systems, accounting software, data interchange, hardware interfacing, etc.  
> 
> 
> 
> Regards,
> 
> 
> 
> Rob

Nic,e I am working on several similar projects including 
EDA automations with expert systems and some VLSI-FPGA IP cores.

Anyway I have to get some US patents first.

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

Re: How to write fast into a file in python?

[88888 Dihedral]

Steven D'Aprano於 2013年5月18日星期六UTC+8下午12時01分13秒寫道：
> On Fri, 17 May 2013 21:18:15 +0300, Carlos Nepomuceno wrote:
> 
> 
> 
> > I thought there would be a call to format method by "'%d\n' % i". It
> 
> > seems the % operator is a lot faster than format. I just stopped using
> 
> > it because I read it was going to be deprecated. :( Why replace such a
> 
> > great and fast operator by a slow method? I mean, why format is been
> 
> > preferred over %?
> 
> 
> 
> That is one of the most annoying, pernicious myths about Python, probably 
> 
> second only to "the GIL makes Python slow" (it actually makes it fast). 
> 
> 

The print function in python  is designed to print 
any printable object with a valid string representation.

The format part of the print function has to construct 
a printable string according to the format string 
and the variables passed in on the fly. 

If the acctual string to be printed in the format processing
is obtained in the high level OOP way , then it is definitely 
slow due to the high level overheads and generality requirements.





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

Re: Python for philosophers

[88888 Dihedral]

Chris Angelico於 2013年5月14日星期二UTC+8上午12時24分44秒寫道：
> On Tue, May 14, 2013 at 12:53 AM, rusi  wrote:
> 
> > int fact(int n, int acc)
> 
> > {
> 
> >   return !n? acc : fact(n-1,acc*n);
> 
> > }
> 
> > -
> 
> > When I run these, the C happily keeps giving answers until a million
> 
> >
> 
> > However examined closely we find that though the C is giving answers
> 
> > its giving junk after around 12
> 
> > fact 17 is -288522240
> 
> > And 35 onwards its 0 (!!)
> 
> 
> 
> That'll depend on your integer size. If it's a 32-bit integer, you
> 
> can't store numbers greater than 2**31-1 (if you declared it as
> 
> 'unsigned int', you could go all the way to 2**32-1). I'm sure you
> 
> could write this to use the GNU Multi-Precision library, but it'd be a
> 
> lot more complicated. However, as far as I know, the Turing machine
> 
> never promises that; its cells aren't meant to be infinite integers.
> 
> 
> 
> The Python script is, of course, governed by sys.setrecursionlimit().
> 
> But by adding a simple driver, we can test the real limit:
> 
> 
> 
> import sys
> 
> 
> 
> def fact(n,acc=1):
> 
> return acc if not n else fact(n-1,n*acc)
> 
> 
> 
> n=2
> 
> while True:
> 
> sys.setrecursionlimit(n+2)
> 
> print("fact",n,"has",len(str(fact(n))),"digits")
> 
> n*=2
> 
> 
> 
> On my 64-bit system, running a recent trunk build of CPython 3.4, it
> 
> can calculate 8192! but not 16384! (segfault). The limit seems to be
> 
> 12772; after that, boom. Your crash-point will quite probably vary,
> 
> and I'd say there'll be compile-time options that would change that.
> 
> 
> 
> Of course, after playing with this in Python, I had to try out Pike.
> 
> Using the exact same code you proposed for C, but with a different
> 
> main() to save me the hassle of keying in numbers manually, I get
> 
> this:
> 
> 
> 
> fact 8192 has 28504 digits - 0.026 secs
> 
> fact 16384 has 61937 digits - 0.097 secs
> 
> fact 32768 has 133734 digits - 0.389 secs
> 
> fact 65536 has 287194 digits - 1.628 secs
> 
> fact 131072 has 613842 digits - 7.114 secs
> 
> fact 262144 has 1306594 digits - 31.291 secs
> 
> fact 524288 has 2771010 digits - 133.146 secs
> 
> 
> 
> It's still going. One core consumed, happily working on 1048576!, and
> 
> not actually using all that much memory. Hmm looks like the Pike
> 
> optimizer has turned this non-recursive. Okay, let's tweak it so it's
> 
> not tail-recursion-optimizable:
> 
> 
> 
>   return n?n*fact(n-1,1):1;
> 
> 
> 
> Now it bombs at 65536, saying:
> 
> 
> 
> Svalue stack overflow. (99624 of 10 entries on stack, needed 256
> 
> more entries)
> 
> 
> 
> Hey, it's better than a segfault, which is what C would have done :)
> 
> And it's a tweakable value, though I don't know what the consequences
> 
> are of increasing it (presumably increased RAM usage for all Pike
> 
> programs).
> 
> 
> 
> Your final conclusion is of course correct; nothing we build can be
> 
> truly infinite. But we can certainly give some very good
> 
> approximations, if we're prepared to pay for them. The reality is,
> 
> though, that we usually do not want to pay for approximations to
> 
> infinity; why is IEEE 754 floating point so much more used than, say,
> 
> arbitrary-precision rational? Most of the time, we'd rather have good
> 
> performance and adequate accuracy than abysmal performance and perfect
> 
> accuracy. But hey, if you want to render a Mandelbrot set and zoom in
> 
> to infinity, the option IS there.
> 
> 
> 
> ChrisA

Hey, ChisA, are you delibrately to write a recursive version
to demonstrate the stack depth problem in Python?

def fact(n):
   ret=1
   if n>1: # integer checking is not used but can be added
  for x in xrange(n): ret*=x
   #print ret # debugging only for long integers 
   return ret 



In a 32 or 64 bit system, this non-recursive verssion
will be limited by the heap space not by the stack limit.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python for philosophers

[88888 Dihedral]

Chris Angelico於 2013年5月19日星期日UTC+8上午8時04分45秒寫道：
> On Sun, May 19, 2013 at 9:56 AM, 88888 Dihedral
> 
>  wrote:
> 
> > Hey, ChisA, are you delibrately to write a recursive version
> 
> > to demonstrate the stack depth problem in Python?
> 
> >
> 
> > def fact(n):
> 
> >ret=1
> 
> >if n>1: # integer checking is not used but can be added
> 
> >   for x in xrange(n): ret*=x
> 
> >#print ret # debugging only for long integers
> 
> >return ret
> 
> >
> 
> >
> 
> >
> 
> > In a 32 or 64 bit system, this non-recursive verssion
> 
> > will be limited by the heap space not by the stack limit.
> 
> 
> 
> And just when we're sure Dihedral's a bot, a post like this comes through.
> 
> 
> 
> Dihedral, are you intelligent? I'm still in two minds about this...
> 
> which may be why you so often appear to have no minds. I dunno.
> 
> Mathematics somewhere I fancy.
> 
> 
> 
> ChrisA

I am too lazy to write a factorial computations with primes
here.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Please help with Threading

[88888 Dihedral]

Chris Angelico於 2013年5月20日星期一UTC+8下午5時09分13秒寫道：
> On Mon, May 20, 2013 at 6:35 PM, Cameron Simpson  wrote:
> 
> >   _lock = Lock()
> 
> >
> 
> >   def lprint(*a, **kw):
> 
> > global _lock
> 
> > with _lock:
> 
> >   print(*a, **kw)
> 
> >
> 
> > and use lprint() everywhere?
> 
> 
> 
> Fun little hack:
> 
> 
> 
> def print(*args,print=print,lock=Lock(),**kwargs):
> 
>   with lock:
> 
> print(*args,**kwargs)
> 
> 
> 
> Question: Is this a cool use or a horrible abuse of the scoping rules?
> 
> 
> 
> ChrisA

OK, if the python interpreter has a global hiden print out
buffer of ,say, 2to 16 K bytes, and all  string print functions
just construct the output string from the format to this string 
in an efficient low level way, then the next question 
would be that whether the uses can use functions in this 
low level buffer for other string formatting jobs.

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

Re: @staticmethods called more than once

[88888 Dihedral]

Ethan Furman於 2013年5月22日星期三UTC+8上午12時30分22秒寫道：
> On 05/21/2013 08:39 AM, Skip Montanaro wrote:
> 
> > Don't confuse the use of "static" in Python with its use in C/C++.  From a 
> > post on StackOverflow:
> 
> >
> 
> > A staticmethod is a method that knows nothing about the class or 
> > instance it was called on. It just gets the
> 
> > arguments that were passed, no implicit first argument. It is basically 
> > useless in Python -- you can just use a
> 
> > module function instead of a staticmethod.
> 
> 
> 
> For there record, staticmethod is useful when you want to make it possible 
> for subclasses to change behavior.
> 
> 
> 
> --
> 
> ~Ethan~

I prefer objects in classes with slimer figures not heavily weighted
with trivial methods in each instance construction and clone.

 But this is only my personal style of classes in python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 378: Format Specifier for Thousands Separator

[88888 Dihedral]

Carlos Nepomuceno於 2013年5月22日星期三UTC+8上午11時38分45秒寫道：
> 
> > From: steve+comp.lang.pyt...@pearwood.info
> > Subject: Re: PEP 378: Format Specifier for Thousands Separator
> > Date: Wed, 22 May 2013 03:08:54 +
> > To: python-list@python.org
> [...]
> >> So, the only alternative to have "'%,d' % x" rendering the thousands
> >> separator output would a C source code modification?
> >
> > That's one alternative. But the language you would be then running will
> > no longer be Python.
> >
> > Another alternative would be to write a pre-processor that parses your
> > Python source code, extracts any reference to the above, and replaces it
> > with a call to the appropriate format call. But not only is that a lot of
> > work for very little gain, but it's also more or less impossible to do in
> > full generality. And again, what you are running will be something
> > different than Python, it will be Python plus a pre-processor.
> >
> >
> > Don't fight the language. You will lose.
> 
> Not fighting the language. In fact it's not even a language issue.
> All I need is a standard library[1] improvement: "%,d"! That's all!
> 
> Just to put in perspective the performance difference of str.__mod__() and 
> str.format():
> 
> C:\Python27>python -m timeit -cv -n1000 "'%d'%12345"
> raw times: 0.386 0.38 0.373
> 1000 loops, best of 3: 0.0373 usec per loop
> 
> C:\Python27>python -m timeit -cv -n1000 "'{:d}'.format(12345)"
> raw times: 7.91 7.89 7.98
> 1000 loops, best of 3: 0.789 usec per loop
> 
> C:\Python27>python -m timeit -cv -n1000 "'{:,d}'.format(12345)"
> raw times: 8.7 8.67 8.78
> 1000 loops, best of 3: 0.867 usec per loop
> 
> That shows str.format() is 20 times slower than str.__mod__() for a simple 
> decimal integer literal formatting.
> And it's additionally 10% slower if the thousands separator format specifier 
> (',') is used.
> 
> [1] I think that translates to Python source code in 'Objects/stringobject.c' 
> and maybe 'Objects/unicodeobject.c'
> 
> >
> >
> > --
> > Steven
> > --
> > http://mail.python.org/mailman/listinfo/python-list

The conversions of the  32 bit integers and 64 bit floats
 to the strings of the  base 10 digits require an 
efficint div and mod normally in the low level.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 378: Format Specifier for Thousands Separator

[88888 Dihedral]

Carlos Nepomuceno於 2013年5月22日星期三UTC+8上午2時49分28秒寫道：
> 
> > From: alyssonbr...@gmail.com 
> > Date: Tue, 21 May 2013 09:03:13 -0300 
> > Subject: Re: PEP 378: Format Specifier for Thousands Separator 
> > To: python-list@python.org 
> >  
> > This work in 3.1+: 
> >  
> > $ python3 
> > Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10) 
> > [GCC 4.4.5] on linux2 
> > Type "help", "copyright", "credits" or "license" for more information. 
> > >>> one_number = 1234567 
> > >>> print('number={:,}'.format(one_number)) 
> > number=1,234,567 
> > >>> 
> >  
> 
> Thank you, but let me rephrase it. I'm already using str.format() but I'd 
> like to use '%' (BINARY_MODULO) operator instead.
> 
> I've looked into the source code of CPython 2.7.5 and I've found no evidence 
> of the thousands separator been implemented on formatint() in 
> "Objects/unicodeobject.c".
> 
> I also didn't find the _PyString_FormatLong() used in formatlong(). Where is 
> _PyString_FormatLong() located?
> 
> So, the question is: Where would I change the CPython 2.7.5 source code to 
> enable '%' (BINARY_MODULO) to format using the thousands separator like 
> str.format() does, such as:
> 
> >>>sys.stderr.write('%,d\n' % 1234567)
> 1,234,567

Could a separate instance like the  I/O device of a subprocess
to be easily available in Python?

The next question would be whether the flow of several I/O data streams could 
be easily piped and manipulated in the high level
programming designs without consuming too much resources.





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

Re: Future standard GUI library

[88888 Dihedral]

Chris Angelico於 2013年5月28日星期二UTC+8下午3時11分55秒寫道：
> On Tue, May 28, 2013 at 9:10 AM, Roy Smith  wrote:
> 
> > In article ,
> 
> >  Chris Angelico  wrote:
> 
> >
> 
> >> I'll use XML when I have to, but if I'm inventing my own protocol,
> 
> >> nope. There are just too many quirks with it. How do you represent an
> 
> >> empty string named Foo?
> 
> >>
> 
> >> 
> 
> >>
> 
> >> or equivalently
> 
> >>
> 
> >> 
> 
> >>
> 
> >> How do you represent an empty list named Foo? The same way. How do you
> 
> >> represent an empty dict/mapping named Foo? Lemme look up my
> 
> >> documentation... ah, the same way. Does this seem right to
> 
> >> you?
> 
> >
> 
> > XML doesn't represent strings, or lists, or dicts.  It represents trees
> 
> > of nodes with labels.  If you wish to invent some richer semantic
> 
> > meaning to impose on those nodes, that's up to you.
> 
> 
> 
> Sure it doesn't, but it's very often used that way. So I guess what
> 
> I'm really saying is that XML is wrong for 90% of the places it's
> 
> used.
> 
> 
> 
> ChrisA

Please check the annual sales in Ebay or similar sites  and the 
advertizement fees collected by Google and Yahoo.





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

Re: Python #ifdef

[88888 Dihedral]

Carlos Nepomuceno於 2013年5月29日星期三UTC+8上午3時46分37秒寫道：
> Are there Python 'preprocessor directives'?
> 
> I'd like to have something like '#ifdef' to mix code from Python 2 and 3 in a 
> single file.
> 
> Is that possible? How?

Use execfile(filename) at the beginning to get what you want.
The .pyc version is preferred.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Future standard GUI library

[88888 Dihedral]

Grant Edwards於 2013年5月29日星期三UTC+8上午2時25分08秒寫道：
> On 2013-05-28, Wolfgang Keller  wrote:
> 
> 
> 
> > Actually productive work of significant intensity at a computer screen.
> 
> 
> 
> Oh. You mean emacs.
> 
> 
> 
> -- 
> 
> Grant Edwards   grant.b.edwardsYow! Will it improve my
> 
>   at   CASH FLOW?
> 
>   gmail.com

Check http://www.pyamf.org/index.html for Python +flash
in browser applications. Annyway the virtual server part 
can be obtained from the Adobe system in the cloudy services 
or whatever.

As long as it is scalable  in fees to provide services
to web users  in PCs or mobile phones,
then it might be very profitable than 10 to 15 years ago.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Short-circuit Logic

[88888 Dihedral]

Steven D'Aprano於 2013年5月30日星期四UTC+8上午10時28分57秒寫道：
> On Wed, 29 May 2013 10:50:47 -0600, Ian Kelly wrote:
> 
> 
> 
> > On Wed, May 29, 2013 at 8:33 AM, rusi  wrote:
> 
> >> 0.0 == 0.0 implies 5.4 == 5.4
> 
> >> is not a true statement is what (I think) Steven is saying. 0 (or if
> 
> >> you prefer 0.0) is special and is treated specially.
> 
> > 
> 
> > It has nothing to do with 0 being special.  A floating point number will
> 
> > always equal itself (except for nan, which is even more special), and in
> 
> > particular 5.4 == 5.4.  But if you have two different calculations that
> 
> > produce 0, or two different calculations that produce 5.4, you might
> 
> > actually get two different numbers that approximate 0 or 5.4 thanks to
> 
> > rounding error.  If you then compare those two ever-so-slightly
> 
> > different numbers, you will find them unequal.
> 
> 
> 
> EXACTLY!
> 
> 
> 
> The problem does not lie with the *equality operator*, it lies with the 
> 
> calculations. And that is an intractable problem -- in general, floating 
> 
> point is *hard*. So the problem occurs when we start with a perfectly 
> 
> good statement of the facts:
> 
> 
> 
> "If you naively test the results of a calculation for equality without 
> 
> understanding what you are doing, you will often get surprising results"
> 
> 
> 
> which then turns into a general heuristic that is often, but not always, 
> 
> reasonable:
> 
> 
> 
> "In general, you should test for floating point *approximate* equality, 
> 
> in some appropriate sense, rather than exact equality"
> 
> 
> 
> which then gets mangled to:
> 
> 
> 
> "Never test floating point numbers for equality"
> 
> 
> 
> and then implemented badly by people who have no clue what they are doing 
> 
> and have misunderstood the nature of the problem, leading to either:
> 
> 
> 
> * de facto exact equality testing, only slower and with the *illusion* of 
> 
> avoiding equality, e.g. "abs(x-y) < sys.float_info.epsilon" is just a 
> 
> long and slow way of saying "x == y" when both numbers are sufficiently 
> 
> large;
> 
> 
> 
> * incorrectly accepting non-equal numbers as "equal" just because they 
> 
> happen to be "close".
> 
> 
> 
> 
> 
> The problem is that there is *no one right answer*, except "have everyone 
> 
> become an expert in floating point, then judge every case on its merits", 
> 
> which will never happen.
> 
> 
> 
> But if nothing else, I wish that we can get past the rank superstition 
> 
> that you should "never" test floats for equality. That would be a step 
> 
> forward.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

The string used to represent a floating number
in a computer language is normally in the decimal base of very 
some limited digits.

Anyway with the advances of A/D-converters in the past 10 years
which are reflected in the anttena- transmitter parts in phones, 
the long integer part in Python can really beat the low cost 
32- 64 bit floating computations in scientific calculations.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Magazine

[88888 Dihedral]

Steven D'Aprano於 2013年5月26日星期日UTC+8上午11時50分31秒寫道：
> On Sat, 25 May 2013 21:54:43 -0400, Roy Smith wrote:
> 
> 
> 
> > Of course not every IPv6 endpoint will be able to talk to every other
> 
> > IPv6 endpoint, even if the both have globally unique addresses.  But,
> 
> > the access controls will be implemented in firewalls with appropriately
> 
> > coded security policies.
> 
> 
> 
> Or, more likely, *not* implemented in firewalls with *inappropriately* 
> 
> coded security policies.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

Well, both the  reliabl tcpip socket and the unstable udp socket 
are supported in Python. 

Aso the html and xml part is supported for the  dirct web page content analysis 
through port 80.

I am not sure whether  Steven is interested in
the web applictions. 

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

Re: Listing modules from all installed packages

[88888 Dihedral]

Carlos Nepomuceno於 2013年6月9日星期日UTC+8下午1時23分15秒寫道：
> print '\n'.join([re.findall("from '(.*)'",str(v))[0] for k,v in 
> sys.modules.items() if str(v).find('from')>-1])
> 
> 
> 
> > Date: Sat, 8 Jun 2013 21:30:48 -0700
> > Subject: Listing modules from all installed packages
> > From: jph...@gmail.com
> > To: pytho...@python.org
> > 
> > Hi,
> > 
> > I'm trying to write a function that programmatically obtains and returns 
> > the exact location of all first-level modules for all installed packages.
> > 
> > For example, if the packages named 'django' and 'django-debug-toolbar' are 
> > installed, I'd like this function to return something like:
> > >>> installed_modules()
> > /Users/my_user/.virtualenvs/my_venv/lib/python2.6/site-packages/django
> > /Users/my_user/.virtualenvs/my_venv/src/debug_toolbar
> > 
> > That is, this function needs to consider all installed packages, including 
> > those that have been installed in "edit" mode (i.e. in the src/ folder). 
> > Note also that the main module for the 'django-debug-toolbar' is in fact 
> > named 'debug_toolbar'.
> > 
> > So far the closest I've been to retrieving the list of first-level modules 
> > is as follows:
> > 
> > import os
> > import pkg_resources
> > import setuptools
> > 
> > pkgs = set()
> > 
> > for dist in pkg_resources.working_set:
> > if os.path.isdir(dist.location):
> > for pkg in setuptools.find_packages(dist.location):
> > if '.' not in pkg:
> > pkgs.add(pkg)
> > 
> > The idea is then to loop through that list of modules, import them and get 
> > their exact locations by fetching their __file__ attribute values.
> > 
> > However, this feels very hackish and I don't think it's actually quite 
> > correct either. I'm sure there must be a better way. If possible I'd also 
> > like to avoid having to use setuptools.
> > 
> > Do you have any tips on how to achieve this?
> > 
> > Many thanks!
> > 
> > Julien
> > -- 
> > http://mail.python.org/mailman/listinfo/python-list

Please use a dictionary to store a tree first.
Then it is trivial to walk through all nodes of the tree.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Default Value

[88888 Dihedral]

rusi於 2013年6月21日星期五UTC+8上午1時12分01秒寫道：
> You know Rick, you are good at python, you are better at polemics.
> 
> If only you would cut the crap I would (be able to) agree with you.
> 
> See below
> 
> 
> 
> On Jun 20, 7:49 pm, Rick Johnson  wrote:
> 
> > On Thursday, June 20, 2013 7:57:06 AM UTC-5, rusi wrote:
> 
> > > Every language has gotchas. This is one of python's.
> 
> >
> 
> > So are we purposely injecting illogic into our language just
> 
> > to be part of some "cool crowd" of programming languages with
> 
> > gotchas.
> 
> >
> 
> >  "You thought intuitiveness was a virtue? Haha, we gotcha!"
> 
> 
> 
> 
> 
> Python (and all the other 'cool' languages) dont have gotchas because
> 
> someone malevolently put them there.
> 
> In most cases, the problem is seen too late and the cost of changing
> 
> entrenched code too great.
> 
> Or the problem is clear, the solution is not etc etc.
> 
> 
> 
> >
> 
> > Or maybe this is reminiscent of the fraternity hazing rituals
> 
> > of days gone by:
> 
> >
> 
> >  *POP*
> 
> >  "Thank you Sir, may i have another?"
> 
> >
> 
> > > If you are a beginning python programmer, really the best
> 
> > > answer is: Just dont do it!  Dont do what? Dont use
> 
> > > mutable arguments as function defaults. Once you cross the
> 
> > > noob stage you can check that its a standard gotcha: Just
> 
> > > run a search for 'python gotcha default []'
> 
> >
> 
> > > And when you feel that you need to, use Steven's trick:
> 
> > > use a immutable indicator 'None' for the mutable []. Once
> 
> > > you cross the noob stage you can check that its a standard
> 
> > > gotcha: Just run a search for 'python gotcha default []'
> 
> > > Its even been discussed repeatedly on the python-ideas
> 
> > > list
> 
> >
> 
> > Your attempting to excuse an inexcusable language flaw by
> 
> > pointing out that the effects of the flaw can be avoided by
> 
> > using a workaround. And, to add insult to injury, you
> 
> > provide no good reason for the flaw to exist:
> 
> >
> 
> >  "Just do x, y, and z and shut up. Yes we made a mistake
> 
> >  but we are not about to admit our mistake and the onerous
> 
> >  will be on all the noobs to re-invent the workaround each
> 
> >  time"
> 
> >
> 
> > To me that is unacceptable.
> 
> >
> 
> > > Heres a correction suggestion: [...] Here's Terry Reedy's
> 
> > > nicely explaining the 'why-of-the-how' : [...] FWIW here
> 
> > > is a conceptual/philosophical explanation of your
> 
> > > confusion: There are 2 fundamental ways for approaching
> 
> > > the programming task -- functional and imperative.
> 
> >
> 
> > All these "explanations" ignore a fundamental fact about
> 
> > subroutines[1].
> 
> 
> 
> >
> 
> > A call to a subroutine should exists as a unique transaction
> 
> > within the entire program. It is expected to optionally take
> 
> > inputs, and optionally return an output (depending on the
> 
> > definition).
> 
> >
> 
> > When the subroutine is completed, all inputs and local
> 
> > variables are expected to be destroyed. If the programmer
> 
> > wants a return value, he need simply ask. Data persistence
> 
> > is not a function of subroutines! Finally, a subroutine
> 
> > should never have side effects UNLESS the programmer
> 
> > explicitly ask for a side effect.
> 
> >
> 
> > However, the Python flaw of allowing mutable sequence
> 
> > arguments to persist between successive calls of a
> 
> > subroutine is breaking the entire definition of a
> 
> > subroutine, and for what noble purpose i ask? What purpose
> 
> > is SO important that you change a well established interface
> 
> > in a totally unintuitive manner?
> 
> >
> 
> > If your answer is that recursion is easier, then i say that
> 
> > is foolish because a programmer can keep a reference
> 
> > to a mutable sequence OUTSIDE the subroutine and you can
> 
> > save the "gotchas" for Guido's next birthday party.
> 
> >
> 
> > [1]:http://en.wikipedia.org/wiki/Subroutine
> 
> 
> 
> 
> 
> You are saying in different language what I said: Functional
> 
> programming is a good idea, imperative programming is a bad idea.
> 
> From the invention of subroutines (ie 50 years) PL designers are
> 
> hearing this truth but somehow or other fail to listen; for more
> 
> details see 
> http://blog.languager.org/2012/11/imperative-programming-lessons-not.html

Well, that was the story of the expensive memory era.the 
In 198X -2000 the auto GC of LISP was beaten 
by practical engineers using C, C++, PASCAL, and object pascal.

But now it is different in 201X.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[88888 Dihedral]

Michael Torrie於 2013年6月20日星期四UTC+8下午2時01分11秒寫道：
> 
>  But since the LISP never really got a form beyond S-expressions,
> 
> leaving us with lots of parenthesis everywhere, Python wins much as the
> 
> Hitchhiker's Guide to the Galaxy wins.

Yep, a list is mutable even it's empty.
But constant integers, floats, strings, and None is immutable.

The  variables in a function of python with default 
parameters which could be mutable or immutable.

def fun1( x, alist=[]):
alist.append(x*x)
return alist   ## valid

def fun2(x, alist=None):
if alist==None: alist=[]
alist.append(x*x)
return alist

# kind of boring to show the name binding mechanism of objects
# in Python in different usages
 




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

Re: FACTS: WHY THE PYTHON LANGUAGE FAILS.

[88888 Dihedral]

Jason Friedman於 2013年6月28日星期五UTC+8上午11時52分33秒寫道：
> > I was hoping to have a good laugh. :|
> 
> 
> 
> 
> 
> > Although I wouldn't call it hostile.
> 
> 
> 
> I think the python community is being educated in how to spam and troll at 
> the same time.
> 
> 
> 
> It is possible the OP has a mental disease, which is about as funny as heart 
> disease and cancer and not blameworthy.  This is the poster's website from a 
> previous post on this forum:  http://thrinaxodon.wordpress.com.

KIND OF BORING TO SHOW HOW THE LISP PROGRAMMING
WAS ASSIMULATED BY THE PYTHON COMMUNITY.

OF COURSE PYTHON IS A GOOD LANGUAGE FOR DEVELOPING
ARTIFICIAL INTELEGENT ROBOT PROGRAMS NOT SO BRAIN DAMAGES,
OR SO SLAVERY AS C/C++ OR ASEMBLY PARTS.



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

Re: Problems with subclassing enum34

[88888 Dihedral]

Thomas Heller於 2013年6月28日星期五UTC+8下午6時48分38秒寫道：
> trying out the enum34 module.
> 
> 
> 
> What I want to create is a subclass of enum.Enum that is also
> 
> based on ctypes.c_int so that I can better use enum instances
> 
> in ctypes api calls.
> 
> 
> 
> When I do this, I get a metaclass conflict:
> 
> 
> 
> 
> 
>  >>> class MyEnum(ctypes.c_int, enum.Enum):
> 
> ...FOOBAR = 0
> 
> ...
> 
> Traceback (most recent call last):
> 
>File "", line 1, in 
> 
> TypeError: Error when calling the metaclass bases
> 
>  metaclass conflict: the metaclass of a derived class must be a 
> 
> (non-strict) subclass of the metaclasses of all its bases
> 
>  >>>
> 
> 
> 
> 
> 
> 
> 
> When I do this, it does not work either:
> 
> 
> 
>  >>> class MyEnum_meta(type(ctypes.c_int), type(enum.Enum)):
> 
> ... pass
> 
> ...
> 
>  >>> class MyEnum(ctypes.c_int, enum.Enum):
> 
> ... FOOBAR = 42
> 
> ... __metaclass__ = MyEnum_meta
> 
> ...
> 
>  >>> MyEnum.FOOBAR
> 
> 42
> 
>  >>>
> 
> 
> 
> It should have printed ''.
> 
> 
> 
> Any ideas?
> 
> 
> 
> Thanks,
> 
> Thomas

Just use a dictionary for the job. Python i not c/c++.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Stupid ways to spell simple code

[88888 Dihedral]

Steven D'Aprano於 2013年7月2日星期二UTC+8上午6時09分18秒寫道：
> On Mon, 01 Jul 2013 20:36:29 +0100, Marcin Szamotulski wrote:
> 
> 
> 
> > Here is another example which I came across when playing with
> 
> > generators, the first function is actually quite useful, the second
> 
> > generator is the whole fun:
> 
> > 
> 
> > from functools import wraps
> 
> > def init(func):
> 
> > """decorator which initialises the generator """
> 
> > @wraps(func)
> 
> > def inner(*args, **kwargs):
> 
> > g = func(*args, **kwargs)
> 
> > g.send(None)
> 
> > return g
> 
> > return inner
> 
> > 
> 
> > @init
> 
> > def gen(func):
> 
> >  x = (yield)
> 
> >  while True:
> 
> >  x = (yield func(x))
> 
> > 
> 
> > 
> 
> > now if you have function f
> 
> > def f(arg):
> 
> > return arg**2
> 
> > 
> 
> > then calling f(5) is the same as
> 
> > 
> 
> > g = gen(f)
> 
> > g.send(5)
> 
> 
> 
> 
> 
> 
> 
> I think you must be missing an important part of the trick, because 
> 
> calling f(5) returns 25. It's not:
> 
> 
> 
> @gen
> 
> def f(arg):
> 
> return arg**2
> 
> 
> 
> 
> 
> because that raises TypeError.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

Lets be serious about generators and iterators.

A generator can be used only once in a program
is different from a a generator method of a class that 
can produce several instances with generators of the same kind
but operated in each instance of the class.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: psutil 1.0.0 released

[88888 Dihedral]

Giampaolo Rodola'於 2013年7月11日星期四UTC+8下午11時02分01秒寫道：
> > Congratulations on the 1.0.0 release!
> 
> 
> 
> Thanks a lot. =)
> 
> 
> 
> >   Btw. any change you can put up a prebuilt installer for a 64-bit built
> 
> > with Python 3.3? You have one for Python 3.2
> 
> > (http://code.google.com/p/psutil/downloads/list), but the version for Python
> 
> > 3.3 is not there.
> 
> 
> 
> Unfortunately I'm having troubles with Visual Studio 64-bit I still
> 
> haven't managed to fix.
> 
> Hope I will get around that soon.
> 
> 
> 
> --- Giampaolo
> 
> 
> 
> http://code.google.com/p/pyftpdlib/
> 
> http://code.google.com/p/psutil/
> 
> http://code.google.com/p/pysendfile/

Do you plan to install 8 or 16 G BYTES DRAM?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RE Module Performance

[88888 Dihedral]

On Saturday, July 13, 2013 1:37:46 PM UTC+8, Steven D'Aprano wrote:
> On Fri, 12 Jul 2013 13:58:29 -0400, Devyn Collier Johnson wrote:
> 
> 
> 
> > I plan to spend some time optimizing the re.py module for Unix systems.
> 
> > I would love to amp up my programs that use that module.
> 
> 
> 
> In my experience, often the best way to optimize a regex is to not use it 
> 
> at all.
> 
> 
> 
> [steve@ando ~]$ python -m timeit -s "import re" \
> 
> > -s "data = 'a'*100+'b'" \
> 
> > "if re.search('b', data): pass"
> 
> 10 loops, best of 3: 2.77 usec per loop
> 
> 
> 
> [steve@ando ~]$ python -m timeit -s "data = 'a'*100+'b'" \
> 
> > "if 'b' in data: pass"
> 
> 100 loops, best of 3: 0.219 usec per loop
> 
> 
> 
> In Python, we often use plain string operations instead of regex-based 
> 
> solutions for basic tasks. Regexes are a 10lb sledge hammer. Don't use 
> 
> them for cracking peanuts.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

OK, lets talk about the indexed search algorithms of 
a character streamor strig which can be buffered and
indexed randomly for RW operations but faster in sequential 
block RW operations after some pre-processing.

This was solved long time ago in the suffix array or 
suffix tree part and summarized in the famous BWT paper in 199X.

Do we want volunteers to speed up 
search operations in the string module in Python?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RE Module Performance

[88888 Dihedral]

Devyn Collier Johnson於 2013年7月16日星期二UTC+8下午6時30分33秒寫道：
> Am 07/12/2013 07:16 PM, schrieb MRAB:
> 
> > On 12/07/2013 23:16, Tim Delaney wrote:
> 
> >> On 13 July 2013 03:58, Devyn Collier Johnson  
> >> > wrote:
> 
> >>
> 
> >>
> 
> >> Thanks for the thorough response. I learned a lot. You should write
> 
> >> articles on Python.
> 
> >> I plan to spend some time optimizing the re.py module for Unix
> 
> >> systems. I would love to amp up my programs that use that module.
> 
> >>
> 
> >>
> 
> >> If you are finding that regular expressions are taking too much time,
> 
> >> have a look at the https://pypi.python.org/pypi/re2/ and
> 
> >> https://pypi.python.org/pypi/regex/2013-06-26 modules to see if they
> 
> >> already give you enough of a speedup.
> 
> >>
> 
> > FYI, you're better off going to http://pypi.python.org/pypi/regex
> 
> > because that will take you to the latest version.
> 
> Thank you everyone for the suggestions. I have not tried them yet.
> 
> 
> 
> Devyn Collier Johnson

I was thinking to decompose RE patterns into string matching 
formats of various strings in some formats.

Anyway that involves some compiler techniques.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[88888 Dihedral]

Albert van der Horst於 2012年6月22日星期五UTC+8下午11時53分01秒寫道：
> In article ,
> Kevin Walzer   wrote:
> >On 6/11/12 8:01 AM, Wolfgang Keller wrote:
> >> Tkinter is imho honestly the very best "argument" if you want to make
> >> potential new users turn their backs away from Python for good. Just
> >> show them one GUI implemented with it and, hey, wait, where are you
> >> running to...
> >
> >Yes, Tkinter GUI's are very ugly.
> >
> >http://www.codebykevin.com/phynchronicity-running.png
> 
> I looked it up.
> 
> What you find ugly, I find unconfusing and clear.
> If I compare it to usual on the web, it is the difference
> between a waterfall side and an airport where the personell
> is on strike. (Oh the noise, the noise is unbearable!).
> I have not, nor intend to write gui things in Python,
> I just give an impression.
> 
> [ I want my gui's to be functional, not beautiful. ]
> 
> 
> >
> >http://www.codebykevin.com/quickwho-main.png
> 
> >--
> >Kevin Walzer
> 
> Groetjes Albert
> 
> 
> 
> --
> -- 
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

I  suggest you can use Python with QT to build some GUI and C++ with QT
 for similar jobs of  the commercial versions in order to test the tools.


Nowadays the GUI part is so cheap to build with so manny code generation tools, 
it is  not the same as in the years before 2000.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: lambda in list comprehension acting funny

[88888 Dihedral]

On Thursday, July 12, 2012 12:34:33 AM UTC+8, Ian wrote:
> On Wed, Jul 11, 2012 at 4:28 AM, Colin J. Williams  wrote:
> > I don't understand why you would expect 1, 2, 4.
> 
> Because:
> 
> funcs[0](2) == 2 ** 0 == 1
> funcs[1](2) == 2 ** 1 == 2
> funcs[2](2) == 2 ** 2 == 4
> 
> > Perhaps parentheses will help the order of evaluation:
> >
> > funcs = [(lambda x: x**i) for i in range( 5 )]
> >
> > This gives:
> > 1
> > 16
> > 81
> 
> No, that gives 16, 16, 16 just like the original.  I don't understand
> why you would expect 1, 16, 81, unless you have misread the code.

I'll contribute my way of python programming:

def powerb(x, b): # 
 return x**b


One functor is enough!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: lambda in list comprehension acting funny

[88888 Dihedral]

On Thursday, July 12, 2012 11:51:04 AM UTC+8, Steven D'Aprano wrote:
> On Wed, 11 Jul 2012 20:39:45 -0700, 8 Dihedral wrote:
> 
> > I'll contribute my way of python programming:
> > 
> > def powerb(x, b): #
> >  return x**b
> 
> Here's a shorter version:
> 
> py> pow
> <built-in function pow>
> 
>  
> > One functor is enough!
> 
> Nothing we have been discussing in this thread has been a functor, either 
> in the Haskell sense or the C++ sense.
> 
> 
> 
> -- 
> Steven

Well, I encountered this kind of problems before in OOP.

I have to make sure my functor to keep the state variable values 
for different objects  that call the same functor to behave correctly
in order to avoid  passing extra parameters in various objects using the same 
functor.

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

Re: lambda in list comprehension acting funny

[88888 Dihedral]

Alister於 2012年7月12日星期四UTC+8下午5時44分15秒寫道：
> On Wed, 11 Jul 2012 08:43:11 +0200, Daniel Fetchinson wrote:
> 
> >> funcs = [ lambda x: x**i for i in range( 5 ) ]
> >> print funcs[0]( 2 )
> >> print funcs[1]( 2 )
> >> print funcs[2]( 2 )
> >>
> >> This gives me
> >>
> >> 16 16 16
> >>
> >> When I was excepting
> >>
> >> 1
> >> 2
> >> 4
> >>
> >> Does anyone know why?
> > 
> > And more importantly, what's the simplest way to achieve the latter? 
> :)
> 
> Having read Steve's explanation in the other thread (which I think has 
> finally flipped the light switch on lambda for me) it only requires a 
> minor change
> 
> funcs=[ lambda x,y=i:x**y for i in range(5) ]
> 
> although I cant actually think why this construct would be needed in 
> practice, how are you actually using it
> 
> 
> -- 
> * Simunye is so happy she has her mothers gene's
>  you better give them back before she misses them!

Uhn, there are 5 objects in the list if not factored well to be executed in 
the run time.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Diagramming code

[88888 Dihedral]

Chris Rebert於 2012年7月16日星期一UTC+8上午9時38分53秒寫道：
> On Sun, Jul 15, 2012 at 6:26 PM, hamilton  wrote:
> > Subject: Diagramming code
> >
> > Is there any software to help understand python code ?
> 
> What sort of diagrams? Control flow diagrams? Class diagrams? Sequence
> diagrams? Module dependency diagrams? There are many different types
> you could be referring to. Here's a relatively comprehensive list:
> http://en.wikipedia.org/wiki/Unified_Modeling_Language#Diagrams_overview
> 
> Regards,
> Chris
> --
> UML: Kill it with fire!

OK, I'll classify OOP by (1) properties of instances of declared classes must 
be fixed such as those in C++ (2) An interpreter could be embedded in the run 
time for an object to evolve through time to accquire properties.


If the robot age was to be comming, what can we do now?

 I think learning python is the high school 
does help a lot for the United States in the future.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: reloading code and multiprocessing

[88888 Dihedral]

andrea crotti於 2012年7月19日星期四UTC+8下午6時15分11秒寫道：
> We need to be able to reload code on a live system.  This live system
> has a daemon process always running but it runs many subprocesses with
> multiprocessing, and the subprocesses might have a short life...
> 
> Now I found a way to reload the code successfully, as you can see from
> this testcase:
> 
> 
> def func():
> from . import a
> print(a.ret())
> 
> 
> class TestMultiProc(unittest.TestCase):
> def setUp(self):
> open(path.join(cur_dir, 'a.py'), 'w').write(old_a)
> 
> def tearDown(self):
> remove(path.join(cur_dir, 'a.py'))
> 
> def test_reloading(self):
> """Starting a new process gives a different result
> """
> p1 = Process(target=func)
> p2 = Process(target=func)
> p1.start()
> res = p1.join()
> open(path.join(cur_dir, 'a.py'), 'w').write(new_a)
> remove(path.join(cur_dir, 'a.pyc'))
> 
> p2.start()
> res = p2.join()
> 
> 
> As long as I import the code in the function and make sure to remove the
> "pyc" files everything seems to work..
> Are there any possible problems which I'm not seeing in this approach or
> it's safe?
> 
> Any other better ways otherwise?

If a byte code interpreter is embedded in the executable, then the program 
can obtain or reload code objects in the run time.

In C/C++, unless one can swap some DLL safely or spawn in another process with 
new executables obtained from other places, or a script interpreter is 
embedded, otherwise it's not easy for an instance in C/C++ to get new methods 
dynamically.

or 

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

Re: Basic question about speed/coding style/memory

[88888 Dihedral]

Jan Riechers於 2012年7月21日星期六UTC+8下午3時33分27秒寫道：
> Hello Pythonlist,
> 
> I have one very basic question about speed,memory friendly coding, and 
> coding style of the following easy "if"-statement in Python 2.7, 
> but Im 
> sure its also the same in Python 3.x
> 
> Block
> #--
> if statemente_true:

if an evaluated expression result is non-zero, then 


>   doSomething()

> else: 
# execute this block if  the expression evaluated as zero
 
>   doSomethingElseInstead()
> 
> #--
> 
> versus this block:
> #--
> if statement_true:
>   doSomething()
>   return
> 
> doSomethingElseInstead()
> 
> #--
> 
> 
> I understand the first pattern that I tell the interpreter to do:
> Check if the conditional is true, run "doSomething()" else go 
> inside the 
> else block and "doSomethingElseInstead()".
> 
> while the 2nd does only checks:
> doSomething() if statement_true, if not, just go directly to 
> "doSomethingElseInstead()
> 
> 
> Now, very briefly, what is the better way to proceed in terms of 
> execution speed, readability, coding style?
> Letting out the fact that, in order to prevent 
> "doSomethingElseInstead"-Block to execute, a return has to provided.
> 
> Thank you for reading and hope someone brings light into that.
> 
> Your fellow python programmer
> Jan

Well, the C-style branching is inherited in python.

Expressions and statements are different.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

[88888 Dihedral]

Chris Angelico於 2012年7月21日星期六UTC+8下午5時04分12秒寫道：
> On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers  
> wrote:
> > Block
> > #--
> > if statemente_true:
> > doSomething()
> > else:
> > doSomethingElseInstead()
> >
> > #--
> 
> This means, to me, that the two options are peers - you do this or you do 
> that.
> 
> > versus this block:
> > #--
> > if statement_true:
> > doSomething()
> > return
> >
> > doSomethingElseInstead()
> >
> > #--
> 
> This would be for an early abort. Don't bother doing most of this
> function's work, just doSomething. Might be an error condition, or
> perhaps an optimized path.
> 
> Definitely for error conditions, I would use the second option. The
> "fail and bail" notation keeps the entire error handling in one 
> place:
> 
> def func(x,y,z):
>   if x<0:
> y+=5
> return
>   if y<0:
> raise PEBKAC("There's an idiot here somewhere")
>   # ... do the rest of the work
> 
This is the caller responsible style when passing parameters to 
functions.


Checking types of parameters both in the caller and the callee 
does slow down a little bit.



> Note the similarity between the control structures. Raising an
> exception immediately terminates processing, without polluting the
> rest of the function with an unnecessary indentation level. Early
> aborting through normal function return can do the same thing.
> 
> But this is purely a matter of style. I don't think there's any
> significance in terms of processing time or memory usage, and even if
> there is, it would be dwarfed by considerations of readability. Make
> your code look like what it's doing, and let the execution take care
> of itself.
> 
> ChrisA

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

Re: Linux shell to python

[88888 Dihedral]

Mark Lawrence於 2012年7月31日星期二UTC+8下午3時15分32秒寫道：
> On 31/07/2012 02:20, Dennis Lee Bieber wrote:
> 
> > On Mon, 30 Jul 2012 22:56:48 +, Dan Stromberg 
> 
> > declaimed the following in gmane.comp.python.general:
> 
> >
> 
> >
> 
> >> Sigh, and I'm also not keen on multi-line list comprehensions, specifically
> 
> >> because I think they tend to make less readable code.  It also becomes a
> 
> >> mess when you need to insert print statements to get some visibility into
> 
> >> what's going on.
> 
> >
> 
> > Cleanly splitting the list-comp by
> 
> >
> 
> > [ result-computation
> 
> > for-item-selection-clause
> 
> > if-filter-clause ]
> 
> >
> 
> > isn't that unreadable... But anyone doing
> 
> >
> 
> > [ result-
> 
> > -computation for-item-
> 
> > -selection-clause if-
> 
> > -filter-
> 
> > -clause ]
> 
> >
> 
> > should be pecked to death by a dead parrot.
> 
> >
> 
> 
> 
> Any particular species?
> 
> 
> 
> -- 
> 
> Cheers.
> 
> 
> 
> Mark Lawrence.

For each item in the known list that passes the required conditional test,
then  use the item to perform the tasks desired as instructed.

It is not necessary that a new list has to be constructed in the tasks.

A method which can produce a new object always involves some memory management. 
Therefore,  some error handling part should not be missing.


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

Re: [newbie] String to binary conversion

[88888 Dihedral]

Steven D'Aprano於 2012年8月7日星期二UTC+8上午10時01分05秒寫道：
> On Mon, 06 Aug 2012 22:46:38 +0200, Mok-Kong Shen wrote:
> 
> 
> 
> > If I have a string "abcd" then, with 8-bit encoding of each character,
> 
> > there is a corresponding 32-bit binary integer. How could I best obtain
> 
> > that integer and from that integer backwards again obtain the original
> 
> > string? Thanks in advance.
> 
> 
> 
> First you have to know the encoding, as that will define the integers you 
> 
> get. There are many 8-bit encodings, but of course they can't all encode 
> 
> arbitrary 4-character strings. Since there are tens of thousands of 
> 
> different characters, and an 8-bit encoding can only code for 256 of 
> 
> them, there are many strings that an encoding cannot handle.
> 
> 
> 
> For those, you need multi-byte encodings like UTF-8, UTF-16, etc.
> 
> 
> 
> Sticking to one-byte encodings: since most of them are compatible with 
> 
> ASCII, examples with "abcd" aren't very interesting:
> 
> 
> 
> py> 'abcd'.encode('latin1')
> 
> b'abcd'
> 
> 
> 
> Even though the bytes object b'abcd' is printed as if it were a string, 
> 
> it is actually treated as an array of one-byte ints:
> 
> 
> 
> py> b'abcd'[0]
> 
> 97
> 
> 
> 
> Here's a more interesting example, using Python 3: it uses at least one 
> 
> character (the Greek letter π) which cannot be encoded in Latin1, and two 
> 
> which cannot be encoded in ASCII:
> 
> 
> 
> py> "aπ©d".encode('iso-8859-7')
> 
> b'a\xf0\xa9d'
> 
> 
> 
> Most encodings will round-trip successfully:
> 
> 
> 
> py> text = 'aπ©Z!'
> 
> py> data = text.encode('iso-8859-7')
> 
> py> data.decode('iso-8859-7') == text
> 
> True
> 
> 
> 
> 
> 
> (although the ability to round-trip is a property of the encoding itself, 
> 
> not of the encoding system).
> 
> 
> 
> Naturally if you encode with one encoding, and then decode with another, 
> 
> you are likely to get different strings:
> 
> 
> 
> py> text = 'aπ©Z!'
> 
> py> data = text.encode('iso-8859-7')
> 
> py> data.decode('latin1')
> 
> 'að©Z!'
> 
> py> data.decode('iso-8859-14')
> 
> 'aŵ©Z!'
> 
> 
> 
> 
> 
> Both the encode and decode methods take an optional argument, errors, 
> 
> which specify the error handling scheme. The default is errors='strict', 
> 
> which raises an exception. Others include 'ignore' and 'replace'.
> 
> 
> 
> py> 'aŵðπ©Z!'.encode('ascii', 'ignore')
> 
> b'aZ!'
> 
> py> 'aŵðπ©Z!'.encode('ascii', 'replace')
> 
> b'aZ!'
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven



Steven D'Aprano於 2012年8月7日星期二UTC+8上午10時01分05秒寫道：
> On Mon, 06 Aug 2012 22:46:38 +0200, Mok-Kong Shen wrote:
> 
> 
> 
> > If I have a string "abcd" then, with 8-bit encoding of each character,
> 
> > there is a corresponding 32-bit binary integer. How could I best obtain
> 
> > that integer and from that integer backwards again obtain the original
> 
> > string? Thanks in advance.
> 
> 
> 
> First you have to know the encoding, as that will define the integers you 
> 
> get. There are many 8-bit encodings, but of course they can't all encode 
> 
> arbitrary 4-character strings. Since there are tens of thousands of 
> 
> different characters, and an 8-bit encoding can only code for 256 of 
> 
> them, there are many strings that an encoding cannot handle.
> 
> 
> 
> For those, you need multi-byte encodings like UTF-8, UTF-16, etc.
> 
> 
> 
> Sticking to one-byte encodings: since most of them are compatible with 
> 
> ASCII, examples with "abcd" aren't very interesting:
> 
> 
> 
> py> 'abcd'.encode('latin1')
> 
> b'abcd'
> 
> 
> 
> Even though the bytes object b'abcd' is printed as if it were a string, 
> 
> it is actually treated as an array of one-byte ints:
> 
> 
> 
> py> b'abcd'[0]
> 
> 97
> 
> 
> 
> Here's a more interesting example, using Python 3: it uses at least one 
> 
> character (the Greek letter π) which cannot be encoded in Latin1, and two 
> 
> which cannot be encoded in ASCII:
> 
> 
> 
> py> "aπ©d".encode('iso-8859-7')
> 
> b'a\xf0\xa9d'
> 
> 
> 
> Most encodings will round-trip successfully:
> 
> 
> 
> py> text = 'aπ©Z!'
> 
> py> data = text.encode('iso-8859-7')
> 
> py> data.decode('iso-8859-7') == text
> 
> True
> 
> 
> 
> 
> 
> (although the ability to round-trip is a property of the encoding itself, 
> 
> not of the encoding system).
> 
> 
> 
> Naturally if you encode with one encoding, and then decode with another, 
> 
> you are likely to get different strings:
> 
> 
> 
> py> text = 'aπ©Z!'
> 
> py> data = text.encode('iso-8859-7')
> 
> py> data.decode('latin1')
> 
> 'að©Z!'
> 
> py> data.decode('iso-8859-14')
> 
> 'aŵ©Z!'
> 
> 
> 
> 
> 
> Both the encode and decode methods take an optional argument, errors, 
> 
> which specify the error handling scheme. The default is errors='strict', 
> 
> which raises an exception. Others include 'ignore' and 'replace'.
> 
> 
> 
> py> 'aŵðπ©Z!'.encode('ascii', 'ignore')
> 
> b'aZ!'
> 
> py> 'aŵðπ©Z!'.encode('ascii', 'replace')
> 
> b'aZ!'
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

I think UTF-8 CODEC or UTF-16 is nece

Re: looking for a neat solution to a nested loop problem

[88888 Dihedral]

Nobody於 2012年8月7日星期二UTC+8下午11時32分55秒寫道：
> On Mon, 06 Aug 2012 21:02:33 -0700, Larry Hudson wrote:
> 
> 
> 
> >>   for i in range(N,N+100):
> 
> >>   for j in range(M,M+100):
> 
> >>   do_something(i % 100 ,j % 100)
> 
> >>
> 
> >> Emile
> 
> > 
> 
> > How about...
> 
> > 
> 
> > for i in range(100):
> 
> >  for j in range(100):
> 
> >  do_something((i + N) % 100, (j + M) % 100)
> 
> 
> 
> Both of these approaches move the modifications to the sequence into the
> 
> body of the loop. It may be preferable to iterate over the desired
> 
> sequence directly. E.g.
> 
> 
> 
>   for i in ((N + ii) % 100 for ii in xrange(100)):
> 
>   for j in ((M + jj) % 100 for jj in xrange(100)):
> 
>   do_something(i, j)



Nobody於 2012年8月7日星期二UTC+8下午11時32分55秒寫道：
> On Mon, 06 Aug 2012 21:02:33 -0700, Larry Hudson wrote:
> 
> 
> 
> >>   for i in range(N,N+100):
> 
> >>   for j in range(M,M+100):
> 
> >>   do_something(i % 100 ,j % 100)
> 
> >>
> 
> >> Emile
> 
> > 
> 
> > How about...
> 
> > 
> 
> > for i in range(100):
> 
> >  for j in range(100):
> 
> >  do_something((i + N) % 100, (j + M) % 100)
> 
> 
> 
> Both of these approaches move the modifications to the sequence into the
> 
> body of the loop. It may be preferable to iterate over the desired
> 
> sequence directly. E.g.
> 
> 
> 
>   for i in ((N + ii) % 100 for ii in xrange(100)):
> 
>   for j in ((M + jj) % 100 for jj in xrange(100)):
> 
>   do_something(i, j)

This is a good example to be tuned into some example 
 such that  this kind of loops by iterators of parameters in python 
wich do not use any division at all.

But I am getting lazy recently for non-critical parts.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: looking for a neat solution to a nested loop problem

[88888 Dihedral]

Nobody於 2012年8月7日星期二UTC+8下午11時32分55秒寫道：
> On Mon, 06 Aug 2012 21:02:33 -0700, Larry Hudson wrote:
> 
> 
> 
> >>   for i in range(N,N+100):
> 
> >>   for j in range(M,M+100):
> 
> >>   do_something(i % 100 ,j % 100)
> 
> >>
> 
> >> Emile
> 
> > 
> 
> > How about...
> 
> > 
> 
> > for i in range(100):
> 
> >  for j in range(100):
> 
> >  do_something((i + N) % 100, (j + M) % 100)
> 
> 
> 
> Both of these approaches move the modifications to the sequence into the
> 
> body of the loop. It may be preferable to iterate over the desired
> 
> sequence directly. E.g.
> 
> 
> 
>   for i in ((N + ii) % 100 for ii in xrange(100)):
> 
>   for j in ((M + jj) % 100 for jj in xrange(100)):
> 
>   do_something(i, j)

list(range(N,100))+ list(range(0,N))  //good for j

Well, this is the way!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: looking for a neat solution to a nested loop problem

[88888 Dihedral]

Nobody於 2012年8月7日星期二UTC+8下午11時32分55秒寫道：
> On Mon, 06 Aug 2012 21:02:33 -0700, Larry Hudson wrote:
> 
> 
> 
> >>   for i in range(N,N+100):
> 
> >>   for j in range(M,M+100):
> 
> >>   do_something(i % 100 ,j % 100)
> 
> >>
> 
> >> Emile
> 
> > 
> 
> > How about...
> 
> > 
> 
> > for i in range(100):
> 
> >  for j in range(100):
> 
> >  do_something((i + N) % 100, (j + M) % 100)
> 
> 
> 
> Both of these approaches move the modifications to the sequence into the
> 
> body of the loop. It may be preferable to iterate over the desired
> 
> sequence directly. E.g.
> 
> 
> 
>   for i in ((N + ii) % 100 for ii in xrange(100)):
> 
>   for j in ((M + jj) % 100 for jj in xrange(100)):
> 
>   do_something(i, j)



Nobody於 2012年8月7日星期二UTC+8下午11時32分55秒寫道：
> On Mon, 06 Aug 2012 21:02:33 -0700, Larry Hudson wrote:
> 
> 
> 
> >>   for i in range(N,N+100):
> 
> >>   for j in range(M,M+100):
> 
> >>   do_something(i % 100 ,j % 100)
> 
> >>
> 
> >> Emile
> 
> > 
> 
> > How about...
> 
> > 
> 
> > for i in range(100):
> 
> >  for j in range(100):
> 
> >  do_something((i + N) % 100, (j + M) % 100)
> 
> 
> 
> Both of these approaches move the modifications to the sequence into the
> 
> body of the loop. It may be preferable to iterate over the desired
> 
> sequence directly. E.g.
> 
> 
> 
>   for i in ((N + ii) % 100 for ii in xrange(100)):
> 
>   for j in ((M + jj) % 100 for jj in xrange(100))

list(range(N,100))+list(range(1,N)) //good for  i

I contribute my python code here to avoid any divison.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: save dictionary to a file without brackets.

[88888 Dihedral]

Andrew Cooper於 2012年8月10日星期五UTC+8上午6時03分26秒寫道：
> On 09/08/2012 22:34, Roman Vashkevich wrote:
> 
> > Actually, they are different.
> 
> > Put a dict.{iter}items() in an O(k^N) algorithm and make it a hundred 
> > thousand entries, and you will feel the difference.
> 
> > Dict uses hashing to get a value from the dict and this is why it's O(1).
> 
> > 
> 
> 
> 
> Sligtly off topic, but looking up a value in a dictionary is actually
> 
> O(n) for all other entries in the dict which suffer a hash collision
> 
> with the searched entry.
> 
> 
> 
> True, a sensible choice of hash function will reduce n to 1 in common
> 
> cases, but it becomes an important consideration for larger datasets.
> 
> 
> 
> ~Andrew

This is the classical problem of storing the hash collision items one by one.
Those items should be stored by some order.

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

Re: save dictionary to a file without brackets.

[88888 Dihedral]

Dave Angel於 2012年8月10日星期五UTC+8上午5時47分45秒寫道：
> On 08/09/2012 05:34 PM, Roman Vashkevich wrote:
> 
> > Actually, they are different.
> 
> > Put a dict.{iter}items() in an O(k^N) algorithm and make it a hundred 
> > thousand entries, and you will feel the difference.
> 
> > Dict uses hashing to get a value from the dict and this is why it's O(1).
> 
> 
> 
> Sure, that's why
> 
> 
> 
> for key in dict:
> 
>   print key[0], key[1], dict[key]
> 
> 
> 
> is probably slower than
> 
> 
> 
> for (edge1, edge2), cost in d.iteritems(): # or .items()
> 
>   print edge1, edge2, cost
> 
> 
> 
> 
> 
> So, the latter is both faster and easier to read.  Why are you arguing 
> against it?
> 
> 
> 
> Also, please stop top-posting.  It's impolite here, and makes it much harder 
> to figure out who is saying what, in what order.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> 
> 
> DaveA

OK, lets estimate the hash colision rate first.

For those items hashed to the same key, I'll store a sorted list with a
known lenth m to be accessed in O(LOG(M)). 

Of couse another hash can be attatched.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: save dictionary to a file without brackets.

[88888 Dihedral]

Steven D'Aprano於 2012年8月11日星期六UTC+8下午7時26分37秒寫道：
> On Fri, 10 Aug 2012 08:53:43 +1000, Chris Angelico wrote:
> 
> 
> 
> > On Fri, Aug 10, 2012 at 8:26 AM, Dave Angel  wrote:
> 
> >> On 08/09/2012 06:03 PM, Andrew Cooper wrote:
> 
> >>> O(n) for all other entries in the dict which suffer a hash collision
> 
> >>> with the searched entry.
> 
> >>>
> 
> >>> True, a sensible choice of hash function will reduce n to 1 in common
> 
> >>> cases, but it becomes an important consideration for larger datasets.
> 
> >>
> 
> >> I'm glad you're wrong for CPython's dictionaries.  The only time the
> 
> >> lookup would degenerate to O[n] would be if the hash table had only one
> 
> >> slot.  CPython sensibly increases the hash table size when it becomes
> 
> >> too small for efficiency.
> 
> >>
> 
> >> Where have you seen dictionaries so poorly implemented?
> 
> > 
> 
> > In vanilla CPython up to version (I think) 3.3, where it's possible to
> 
> > DoS the hash generator. Hash collisions are always possible, just
> 
> > ridiculously unlikely unless deliberately exploited.
> 
> 
> 
> Not so unlikely actually.
> 
> 
> 
> py> hash(3)
> 
> 3
> 
> py> hash(2**64 + 2)
> 
> 3
> 
> 
> 
> py> hash(-1)
> 
> -2
> 
> py> hash(-2)
> 
> -2
> 
> 
> 
> 
> 
> By its very nature, a hash function cannot fail to have collisions. The 
> 
> problem is that in general you have an essentially unlimited number of 
> 
> objects being mapped to a large but still finite number of hash values.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven



Steven D'Aprano於 2012年8月11日星期六UTC+8下午7時26分37秒寫道：
> On Fri, 10 Aug 2012 08:53:43 +1000, Chris Angelico wrote:
> 
> 
> 
> > On Fri, Aug 10, 2012 at 8:26 AM, Dave Angel  wrote:
> 
> >> On 08/09/2012 06:03 PM, Andrew Cooper wrote:
> 
> >>> O(n) for all other entries in the dict which suffer a hash collision
> 
> >>> with the searched entry.
> 
> >>>
> 
> >>> True, a sensible choice of hash function will reduce n to 1 in common
> 
> >>> cases, but it becomes an important consideration for larger datasets.
> 
> >>
> 
> >> I'm glad you're wrong for CPython's dictionaries.  The only time the
> 
> >> lookup would degenerate to O[n] would be if the hash table had only one
> 
> >> slot.  CPython sensibly increases the hash table size when it becomes
> 
> >> too small for efficiency.
> 
> >>
> 
> >> Where have you seen dictionaries so poorly implemented?
> 
> > 
> 
> > In vanilla CPython up to version (I think) 3.3, where it's possible to
> 
> > DoS the hash generator. Hash collisions are always possible, just
> 
> > ridiculously unlikely unless deliberately exploited.
> 
> 
> 
> Not so unlikely actually.
> 
> 
> 
> py> hash(3)
> 
> 3
> 
> py> hash(2**64 + 2)
> 
> 3
> 
> 
> 
> py> hash(-1)
> 
> -2
> 
> py> hash(-2)
> 
> -2
> 
> 
> 
> 
> 
> By its very nature, a hash function cannot fail to have collisions. The 
> 
> problem is that in general you have an essentially unlimited number of 
> 
> objects being mapped to a large but still finite number of hash values.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

Lets check the basic operations of a hash table or so-called a dictionary first.

If the dictionary is implemented toward faster in searching items, 
then it is slightly different in the insertion and the deletion operations of
(key, value) pairs.


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

Re: looking for a neat solution to a nested loop problem

[88888 Dihedral]

Nobody於 2012年8月7日星期二UTC+8下午11時32分55秒寫道：
> On Mon, 06 Aug 2012 21:02:33 -0700, Larry Hudson wrote:
> 
> 
> 
> >>   for i in range(N,N+100):
> 
> >>   for j in range(M,M+100):
> 
> >>   do_something(i % 100 ,j % 100)
> 
> >>
> 
> >> Emile
> 
> > 
> 
> > How about...
> 
> > 
> 
> > for i in range(100):
> 
> >  for j in range(100):
> 
> >  do_something((i + N) % 100, (j + M) % 100)
> 
> 
> 
> Both of these approaches move the modifications to the sequence into the
> 
> body of the loop. It may be preferable to iterate over the desired
> 
> sequence directly. E.g.
> 
> 
> 
>   for i in ((N + ii) % 100 for ii in xrange(100)):
> 
>   for j in ((M + jj) % 100 for jj in xrange(100)):
> 
>   do_something(i, j)

I'll contrubute another version by the xrange function in python.

for i in xrange(N, N+100): # not list based
if i<100: i2=i else: i2=i-100 # not in the inner most loop
for j in xrange(M, M+100):
if j<100: j2=j else: j2=j-100
do_something(i2,j2)



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

Re: New image and color management library for Python 2+3

[88888 Dihedral]

Christian Heimes於 2012年8月15日星期三UTC+8上午2時22分54秒寫道：
> Hello fellow Pythonistas,
> 
> 
> 
> I'm looking for co-developers, testers, documentation writers and users
> 
> for a new image library I created. The code is available at
> 
> https://bitbucket.org/tiran/smc.freeimage
> 
> 
> 
> 
> 
> Background story:
> 
> I'm working for a company that creates Python based solutions for
> 
> libraries -- these large buildings containg millions of books. One major
> 
> area of operation is the digitalization of books, prints and manuscripts
> 
> from the last millennium. We are a major player in the German speaking
> 
> countries with several hundred Terabytes of images on all our installations.
> 
> 
> 
> Several years ago I began to write a Python interface for FreeImage
> 
> because I was unhappy with the speed and capabilities of PIL. We had to
> 
> check and convert several hundred GB of TIFF images to up to 15 sizes
> 
> each and store them as JPEG every week. FreeImage offered more features
> 
> and speed. Cython made it possible to integrate FreeImage into our
> 
> software stack nicely. Later LittleCMS was integrated as color
> 
> management solution to convert images from the scanners' color space
> 
> into sRGB.
> 
> 
> 
> During the development of smc.freeimage I also created a fork of
> 
> FreeImage that wraps libjpeg-turbo instead of libjpeg.
> 
> 
> 
> 
> 
> In my opinion the project is useful for other people because it has some
> 
> benefits over PIL. For example it supports modern file formats that
> 
> aren't supported by PIL, for example JPEG 2000, HDR formats and RAW
> 
> camera formats. Contrary to PIL it even supports G3 and G4 compressed
> 
> TIIFs as well as multipage TIFFs. In some areas it's also much faster
> 
> than PIL, especially JPEG performance and NumPy buffer access.
> 
> 
> 
> However it's not going to replace PIL as neither FreeImage nor my code
> 
> supports drawing, text composition or extended filters.
> 
> 
> 
> 
> 
> Excerpt from the README:
> 
> 
> 
> Features of FreeImage
> 
> =
> 
> 
> 
> FreeImage wraps mature and widely-used libraries like LibJPEG,
> 
> LibOpenJPEG,LibPNG, LibRaw, LibTIFF4, OpenEXR and zlib in a consistent,
> 
> well documented and powerful set of APIs.
> 
> 
> 
> http://freeimage.sourceforge.net/
> 
> 
> 
> Reading of 35 file formats and writing of more than 19 file formats as
> 
> of FreeImage 3.15.3, including JPEG 2000, multiple subformats of TIFF
> 
> with G3/G4 fax compression and JPEG subsampling.
> 
> 
> 
> pixel depths from 1-32 bpp standard images up to formats like RGBAF and
> 
> 2x64complex.
> 
> 
> 
> multi page images
> 
> 
> 
> Metadata (e.g. EXIF, IPTC/NAA, GeoTIFF, XMP) and ICC
> 
> 
> 
> Color adjustment, conversion and channel processing
> 
> 
> 
> Image resizing and rotation
> 
> 
> 
> High Dynamic Range (HDR) image processing and tone mapping
> 
> 
> 
> RAW camera files
> 
> 
> 
> Contrary to PIL it doesn't contain advanced image filters or drawing
> 
> functions. FreeImage focuses on file formats
> 
> 
> 
> 
> 
> Features of LCMS2
> 
> =
> 
> 
> 
> LCMS2 is a color management engine that implements V2 and V4 ICC
> 
> profiles up to V4.3. It supports transformation, proofing and
> 
> introspection of profiles for a large variety of color formats and targets.
> 
> 
> 
> http://www.littlecms.com/
> 
> 
> 
> 
> 
> Features of smc.freeimage
> 
> =
> 
> 
> 
> smc.freeimage is developed as part of the closed source Visual Library
> 
> framework.
> 
> 
> 
> mostly written with Cython with some lines of handwritten C Code and
> 
> some Python helpers.
> 
> 
> 
> fast, it avoids copying large amounts of data and releases the GIL
> 
> whenever possible.
> 
> 
> 
> 64bit safe, tested on i386/X86 and AMD64/X86_64 systems
> 
> 
> 
> thread safe
> 
> 
> 
> wraps a large subset of FreeImage features
> 
> 
> 
> Compatible with Python 2.6 to 3.3.
> 
> 
> 
> 
> 
> Performance
> 
> ===
> 
> 
> 
> smc.freeimage with libjpeg-turbo read JPEGs about three to six times
> 
> faster than PIL and writes JPEGs more than five times faster.
> 
> 
> 
> JPEG's restart markers are not compatible with libjpeg-turbo's Huffman
> 
> decoder optimization and reduce performance a lot. Please read the
> 
> section "Restart Makers" on the page
> 
> http://www.libjpeg-turbo.org/About/Performance for more information.
> 
> 
> 
> Python 2.7.3
> 
> read / write cycles: 300
> 
> test image: 1210x1778 24bpp JPEG (pon.jpg)
> 
> platform: Ubuntu 12.04 X86_64
> 
> hardware: Intel Xeon hexacore W3680@3.33GHz with 24 GB RAM
> 
> 
> 
> smc.freeimage, FreeImage 3.15.3 standard
> 
>  - read JPEG 12.857 sec
> 
>  - read JPEG 6.629 sec (resaved)
> 
>  - write JPEG 21.817 sec
> 
> smc.freeimage, FreeImage 3.15.3 with jpeg turbo
> 
>  - read JPEG 9.297 sec
> 
>  - read JPEG 3.909 sec (resaved)
> 
>  - write JPEG 5.857 sec
> 
>  - read LZW TIFF 17.947 sec
> 
>  - read biton G4 TIFF 2.068 sec
> 
>  - resize 3.850 sec (box)
> 
>

Re: How do I display unicode value stored in a string variable using ord()

[88888 Dihedral]

On Monday, August 20, 2012 1:03:34 AM UTC+8, Blind Anagram wrote:
> "Steven D'Aprano"  wrote in message 
> 
> news:502f8a2a$0$29978$c3e8da3$54964...@news.astraweb.com...
> 
> 
> 
> On Sat, 18 Aug 2012 01:09:26 -0700, wxjmfauth wrote:
> 
> 
> 
> [...]
> 
> If you can consistently replicate a 100% to 1000% slowdown in string
> 
> handling, please report it as a performance bug:
> 
> 
> 
> http://bugs.python.org/
> 
> 
> 
> Don't forget to report your operating system.
> 
> 
> 
> 
> 
> For interest, I ran your code snippets on my laptop (Intel core-i7 1.8GHz) 
> 
> running Windows 7 x64.
> 
> 
> 
> Running Python from a Windows command prompt,  I got the following on Python 
> 
> 3.2.3 and 3.3 beta 2:
> 
> 
> 
> python33\python" -m timeit "('abc' * 1000).replace('c', 'de')"
> 
> 1 loops, best of 3: 39.3 usec per loop
> 
> python33\python" -m timeit "('ab…' * 1000).replace('…', '……')"
> 
> 1 loops, best of 3: 51.8 usec per loop
> 
> python33\python" -m timeit "('ab…' * 1000).replace('…', 'x…')"
> 
> 1 loops, best of 3: 52 usec per loop
> 
> python33\python" -m timeit "('ab…' * 1000).replace('…', 'œ…')"
> 
> 1 loops, best of 3: 50.3 usec per loop
> 
> python33\python" -m timeit "('ab…' * 1000).replace('…', '€…')"
> 
> 1 loops, best of 3: 51.6 usec per loop
> 
> python33\python" -m timeit "('XYZ' * 1000).replace('X', 'éç')"
> 
> 1 loops, best of 3: 38.3 usec per loop
> 
> python33\python" -m timeit "('XYZ' * 1000).replace('Y', 'p?')"
> 
> 1 loops, best of 3: 50.3 usec per loop
> 
> 
> 
> python32\python" -m timeit "('abc' * 1000).replace('c', 'de')"
> 
> 1 loops, best of 3: 24.5 usec per loop
> 
> python32\python" -m timeit "('ab…' * 1000).replace('…', '……')"
> 
> 1 loops, best of 3: 24.7 usec per loop
> 
> python32\python" -m timeit "('ab…' * 1000).replace('…', 'x…')"
> 
> 1 loops, best of 3: 24.8 usec per loop
> 
> python32\python" -m timeit "('ab…' * 1000).replace('…', 'œ…')"
> 
> 1 loops, best of 3: 24 usec per loop
> 
> python32\python" -m timeit "('ab…' * 1000).replace('…', '€…')"
> 
> 1 loops, best of 3: 24.1 usec per loop
> 
> python32\python" -m timeit "('XYZ' * 1000).replace('X', 'éç')"
> 
> 1 loops, best of 3: 24.4 usec per loop
> 
> python32\python" -m timeit "('XYZ' * 1000).replace('Y', 'p?')"
> 
> 1 loops, best of 3: 24.3 usec per loop
> 
> 
> 
> This is an average slowdown by a factor of close to 2.3 on 3.3 when compared 
> 
> with 3.2.
> 
> 
> 
> I am not posting this to perpetuate this thread but simply to ask whether, 
> 
> as you suggest, I should report this as a possible problem with the beta?

Un, another set of functions for seeding up ASCII string othe pertions 
might be needed. But it is better that Python 3.3 supports unicode strings
to be easy to be used by people in different languages first.

Anyway I think Cython and Pyrex can be used to tackle this problem.


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

Re: Why doesn't Python remember the initial directory?

[88888 Dihedral]

On Monday, August 20, 2012 4:42:16 AM UTC+8, kj wrote:
> As far as I've been able to determine, Python does not remember
> 
> (immutably, that is) the working directory at the program's start-up,
> 
> or, if it does, it does not officially expose this information.
> 
> 
> 
> Does anyone know why this is?  Is there a PEP stating the rationale
> 
> for it?
> 
> 
> 
> Thanks!

Immutable data can be frozen and saved in somewhere off the main memory.

Perative and imperative programming are different.

Please check Erlang.

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

Re: Abuse of Big Oh notation

[88888 Dihedral]

Paul Rubin於 2012年8月21日星期二UTC+8上午3時29分12秒寫道：
> Ian Kelly  writes:
> 
> > The difference between the two is that the former is bounded by a
> 
> > constant that is fundamental to the algorithm at hand,...  S is
> 
> > clearly bounded by the constraints of actual shoes, so we can safely
> 
> > treat S as a constant and call it O(N).
> 
> 
> 
> Thanks, that is a good explain of what I was trying to get at.  One
> 
> quibble is in the parsing example, the constant is inherent in the
> 
> distribution of input data one expects to normally encounter, rather
> 
> than in the algorithm itself.  It's sort of like saying dictionary
> 
> access (based on hashing) is O(1), based on the variety of input data
> 
> that is normally used.  There is such a thing as pathological
> 
> (e.g. malicious) input data that causes a lot of hash collisions, making
> 
> O(n) access in the size of the dictionary.  
> 
> 
> 
> I suppose abnormal input should also be taken into account in examples
> 
> involving parsing if one parses potentially hostile data.

OK, the hash key function has to be seeded with some randomization 
in the begining of a hash table from some data independent factors.

Also for those items hashed to the same key with a length >=16
I think an insertion sort is good in soring a sorted list of items hashed to
the same key of a length 16 to 256 or even larger which indicates 
the hash function should be changed from time to time in the 
occasions of resizing the hash table when the table is under a lot operations
of  item inserstions and deletions which are much greater than the number 
of item searches in the same period.
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Abuse of Big Oh notation

[88888 Dihedral]

Paul Rubin於 2012年8月21日星期二UTC+8上午3時29分12秒寫道：
> Ian Kelly  writes:
> 
> > The difference between the two is that the former is bounded by a
> 
> > constant that is fundamental to the algorithm at hand,...  S is
> 
> > clearly bounded by the constraints of actual shoes, so we can safely
> 
> > treat S as a constant and call it O(N).
> 
> 
> 
> Thanks, that is a good explain of what I was trying to get at.  One
> 
> quibble is in the parsing example, the constant is inherent in the
> 
> distribution of input data one expects to normally encounter, rather
> 
> than in the algorithm itself.  It's sort of like saying dictionary
> 
> access (based on hashing) is O(1), based on the variety of input data
> 
> that is normally used.  There is such a thing as pathological
> 
> (e.g. malicious) input data that causes a lot of hash collisions, making
> 
> O(n) access in the size of the dictionary.  
> 
> 
> 
> I suppose abnormal input should also be taken into account in examples
> 
> involving parsing if one parses potentially hostile data.

OK, the hash key function has to be seeded with some randomization 
in the creation of a hash table from some data independent factors.

Also for those items hashed to the same key with a length >=16
I think an insertion sort and a heap sort are good in storing a sorted list of 
items hashed to the same key of a length 16 to 256 or even larger which 
indicates  the hash function should be changed from time to time in the
occasions of resizing the hash table when the table is under a lot operations
of  item insertions and deletions which  are operated  much frequently 
than the number of item searches in the same period.


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

Re: Objects in Python

[88888 Dihedral]

Jan Kuiken於 2012年8月24日星期五UTC+8上午2時02分00秒寫道：
> On 8/23/12 06:11 , Steven D'Aprano wrote:
> 
> 
> 
> >> 2) Related to the above, you can infinitely nest scopes. There's nothing
> 
> >> wrong with having six variables called 'q'; you always use the innermost
> 
> >> one. Yes, this can hurt readability
> 
> >
> 
> > Well, there you go. There *is* something wrong with having six variables
> 
> > called 'q'.
> 
> 
> 
> Sometimes you don't want only six variables called 'q' but a hundred
> 
> of them :-)
> 
> 
> 
>def fac(q):
> 
>if q < 1 :
> 
>return 1
> 
>else:
> 
>return q * fac(q-1)
> 
> 
> 
>print(fac(100))
> 


> 
> 
> 
> 
> Jan Kuiken

The long integer arithmetic operations are built in. 
This makes mathematicians and designers focused on the theory side.


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

Re: Unittest - testing for filenames and filesize

[88888 Dihedral]

On Saturday, September 1, 2012 12:19:10 AM UTC+8, Chris Withers wrote:
> On 23/08/2012 12:25, Tigerstyle wrote:
> 
> > class FileTest(unittest.TestCase):
> 
> >
> 
> >  def setUp(self):
> 
> >  self.origdir = os.getcwd()
> 
> >  self.dirname = tempfile.mkdtemp("testdir")
> 
> >  os.chdir(self.dirname)
> 
> 
> 
> I wouldn't change directories like this, it's pretty fragile, just use 
> 
> absolute paths.
> 
> 
> 
> >  def test_1(self):
> 
> >  "Verify creation of files is possible"
> 
> >  for filename in ("this.txt", "that.txt", "the_other.txt"):
> 
> >  f = open(filename, "w")
> 
> >  f.write("Some text\n")
> 
> >  f.close()
> 
> >  self.assertTrue(f.closed)
> 
> >
> 
> >  def test_2(self):
> 
> >  "Verify that current directory is empty"
> 
> >  self.assertEqual(glob.glob("*"), [], "Directory not empty")
> 
> >
> 
> >  def tearDown(self):
> 
> >  os.chdir(self.origdir)
> 
> >  shutil.rmtree(self.dirname)
> 
> 
> 
> Seeing this, you might find the following tools useful:
> 
> 
> 
> http://packages.python.org/testfixtures/files.html
> 
> 
> 
> cheers,
> 
> 
> 
> Chris
> 
> 
> 
> -- 
> 
> Simplistix - Content Management, Batch Processing & Python Consulting
> 
>  - http://www.simplistix.co.uk

Well, I am thinking  that the directory tree listing services or daemons
supported by the OS by some iterators could be better than the stack
based model.

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

Re: set and dict iteration

[88888 Dihedral]

Paul Rubin於 2012年8月17日星期五UTC+8上午9時01分39秒寫道：
> Ian Kelly  writes:
> 
> > With regard to key insertion and deletion while iterating over a dict
> 
> > or set, though, there is just no good reason to be doing that
> 
> > (especially as the result is very implementation-specific), and I
> 
> > wouldn't mind a more complete low-level check against it as long as
> 
> > it's not too expensive (which is not clearly the case with the current
> 
> > suggestion at all).
> 
> 
> 
> One possible approach is to freeze the dictionary against modification
> 
> while any iterator is open on it.  You could keep a count of active
> 
> iterators in the dict structure, adjusting it whenever an iterator is
> 
> created or closed/destroyed.

If there is only one iterator of a frozen dictionary,
then nothing is saved.

But if there are manny iterators based on the same frozen dictionary, 
this approach saves a lot. 



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

Re: Python presentations

[88888 Dihedral]

mblume於 2012年9月14日星期五UTC+8上午12時26分17秒寫道：
> Am Thu, 13 Sep 2012 17:00:19 +0100 schrieb andrea crotti:
> 
> >
> 
> > I have to give a couple of Python presentations in the next weeks, and
> 
> > I'm still thinking what is the best approach.
> 
> > 
> 
> My idea for an introductory presentation of python was to prepare some 
> 
> code snippets (all valid python), show them in the editor, explain them,
> 
> then run in a console. 
> 
> 
> 
> Beginners could then use these code snippets for their own experiments.
> 
> 
> 
> HTH
> 
> Martin

I'll contribute one point in Python. 

def powerlist(x, n):
# n is a natural number
 result=[]
 y=1
 for i in xrange(n):
result.append(y) 
y*=x
 return result # any object in the local function can be returned
 
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python presentations

[88888 Dihedral]

Chris Angelico於 2012年9月14日星期五UTC+8上午6時39分25秒寫道：
> On Fri, Sep 14, 2012 at 8:33 AM, Alexander Blinne  wrote:
> 
> > On 13.09.2012 21:01, 88888 Dihedral wrote:
> 
> >> def powerlist(x, n):
> 
> >> # n is a natural number
> 
> >>  result=[]
> 
> >>  y=1
> 
> >>  for i in xrange(n):
> 
> >> result.append(y)
> 
> >> y*=x
> 
> >>  return result # any object in the local function can be returned
> 
> >
> 
> > def powerlist(x, n):
> 
> > result=[1]
> 
> > for i in xrange(n-1):
> 
> > result.append(result[-1]*x)
> 
> > return result
> 
> >
> 
> > def powerlist(x,n):
> 
> > if n==1:
> 
> > return [1]
> 
> > p = powerlist(x,n-1)
> 
> > return p + [p[-1]*x]
> 
> 
> 
> Eh, much simpler.
> 
> 
> 
> def powerlist(x,n):
> 
>   return [x*i for i in xrange(n-1)]
> 
> 
> 
> But you're responding to a bot there. Rather clever as bots go, though.
> 
> 
> 
> ChrisA

I do not object the list comprehension in concept. 
But I have to convert python code to cython from time to time.

Well, this imposes some coding style definitely.
 


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

Re: Decorators not worth the effort

[88888 Dihedral]

Chris Angelico於 2012年9月14日星期五UTC+8下午10時41分06秒寫道：
> On Sat, Sep 15, 2012 at 12:12 AM, andrea crotti
> 
>  wrote:
> 
> > def fib(n):
> 
> > if n <= 1:
> 
> > return 1
> 
> > return fib(n-1) + fib(n-2)
> 
> >
> 
> > @memoize
> 
> > def fib_memoized(n):
> 
> > if n <= 1:
> 
> > return 1
> 
> > return fib_memoized(n-1) + fib_memoized(n-2)
> 
> >
> 
> >
> 
> > The second fibonacci looks exactly the same but while the first is
> 
> > very slow and would generate a stack overflow the second doesn't..
> 
> 
> 
> Trouble is, you're starting with a pretty poor algorithm. It's easy to
> 
> improve on what's poor. Memoization can still help, but I would start
> 
> with a better algorithm, such as:
> 
> 
> 
> def fib(n):
> 
>   if n<=1: return 1
> 
>   a,b=1,1
> 
>   for i in range(1,n,2):
> 
>   a+=b
> 
>   b+=a
> 
>   return b if n%2 else a
> 
> 
> 
> def fib(n,cache=[1,1]):
> 
>   if n<=1: return 1
> 
>   while len(cache)<=n:
> 
>   cache.append(cache[-1] + cache[-2])
> 
>   return cache[n]
> 
> 
> 
> Personally, I don't mind (ab)using default arguments for caching, but
> 
> you could do the same sort of thing with a decorator if you prefer. I
> 
> think the non-decorated non-recursive version is clear and efficient
> 
> though.
> 
> 
> 
> ChrisA

Uhn, the decorator part is good for wrapping functions in python.

For example a decorator can be used  to add a layor of some
message handlings of  those  plain functions
to become iterators which could be used as call back functions
in a more elegant way.



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

Re: Decorators not worth the effort

[88888 Dihedral]

Steven D'Aprano於 2012年9月15日星期六UTC+8上午7時39分28秒寫道：
> On Fri, 14 Sep 2012 15:16:47 -0600, Ian Kelly wrote:
> 
> 
> 
> > If only there were a conceptually simpler way to do this.  Actually,
> 
> > there is.  I give you: metadecorators!
> 
> [code snipped but shown below]
> 
> > Which I think is certainly easier to understand than the nested
> 
> > functions approach.
> 
> 
> 
> Maybe for you, but to me it is a big ball of mud. I have no idea how this 
> 
> is supposed to work! At a quick glance, I would have sworn that it 
> 
> *can't* work, since simple_decorator needs to see multiple arguments but 
> 
> only receives one, the function to be decorated. And yet it does work:
> 
> 
> 
> py> from functools import partial
> 
> py> def make_wrapper(wrapper):
> 
> ... return lambda wrapped: partial(wrapper, wrapped)
> 
> ...
> 
> py> @make_wrapper
> 
> ... def simple_decorator(func, *args, **kwargs):
> 
> ... print "Entering decorated function"
> 
> ... result = func(*args, **kwargs)
> 
> ... print "Exiting decorated function"
> 
> ... return result
> 
> ...
> 
> py> @simple_decorator
> 
> ... def my_function(a, b, c):
> 
> ... """Doc string"""
> 
> ... return a+b+c
> 
> ...
> 
> py> my_function(1, 2, 3)
> 
> Entering decorated function
> 
> Exiting decorated function
> 
> 6
> 
> 
> 
> So to me, this is far more magical than nested functions. If I saw this 
> 
> in t requires me to hunt through your library for the "simple function 
> 
> buried in a utility module somewhere" (your words), instead of seeing 
> 
> everything needed in a single decorator factory function. It requires 
> 
> that I understand how partial works, which in my opinion is quite tricky. 
> 
> (I never remember how it works or which arguments get curried.)
> 
> 
> 
> And the end result is that the decorated function is less debugging-
> 
> friendly than I demand: it is an anonymous partial object instead of a 
> 
> named function, and the doc string is lost. And it is far from clear to 
> 
> me how to modify your recipe to use functools.wraps in order to keep the 
> 
> name and docstring, or even whether I *can* use functools.wraps.
> 
> 
> 
> I dare say I could answer all those questions with some experimentation 
> 
> and research. But I don't think that your "metadecorator" using partial 
> 
> is *inherently* more understandable than the standard decorator approach:
> 
> 
> 
> def simple_decorator2(func):
> 
> @functools.wraps(func)
> 
> def inner(*args, **kwargs):
> 
> print "Entering decorated function"
> 
> result = func(*args, **kwargs)
> 
> print "Exiting decorated function"
> 
> return result
> 
> return inner
> 
> 
> 
> This is no more complex than yours, and it keeps the function name and 
> 
> docstring.
> 
> 
> 
> 
> 
> > Parameterized decorators are not much more
> 
> > difficult this way.  This function:
> 
> [snip code]
> 
> > And now we have a fancy parameterized decorator that again requires no
> 
> > thinking about nested functions at all.
> 
> 
> 
> Again, at the cost of throwing away the function name and docstring.
> 
> 
> 
> I realise that a lot of this boils down to personal preference, but I 
> 
> just don't think that nested functions are necessarily that hard to 
> 
> grasp, so I prefer to see as much of the decorator logic to be in one 
> 
> place (a nested decorator function) rather than scattered across two 
> 
> separate decorators plus partial.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven
 

I think the problem is not in the replaced f.__doc__.

 
def MIGHT_FAIL(f, MSG, *k, **h):
 
# use MSG to determine whether  to invoke f or not 
# and do an error catch  here
 
 def innner(f): .
 ..
 # get the right info of  f here for any trapped error   
 #return inner, result
 return inner
  

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

Re: Decorators not worth the effort

[88888 Dihedral]

David Hutto於 2012年9月15日星期六UTC+8下午6時04分28秒寫道：
> On Sat, Sep 15, 2012 at 5:45 AM, 88888 Dihedral
> 
>  wrote:
> 
> > Steven D'Aprano於 2012年9月15日星期六UTC+8上午7時39分28秒寫道：
> 
> >> On Fri, 14 Sep 2012 15:16:47 -0600, Ian Kelly wrote:
> 
> >>
> 
> >>
> 
> >>
> 
> >> > If only there were a conceptually simpler way to do this.  Actually,
> 
> >>
> 
> >> > there is.  I give you: muman than humanetadecorators!
> 
> >>
> 
> >> [code snipped but shown below]
> 
> >>
> 
> >> > Which I think is certainly easier to understand than the nested
> 
> >>
> 
> >> > functions approach.
> 
> >>
> 
> >>
> 
> >>
> 
> >> Maybe for you, but to me it is a big ball of mud. I have no idea how this
> 
> >>
> 
> >> is supposed to work! At a quick glance, I would have sworn that it
> 
> >>
> 
> >> *can't* work, since simple_decorator needs to see multiple arguments but
> 
> >>
> 
> >> only receives one, the function to be decorated. And yet it does work:
> 
> >>
> 
> >>
> 
> >>
> 
> >> py> from functools import partial
> 
> >>
> 
> >> py> def make_wrapper(wrapper):
> 
> >>
> 
> >> ... return lambda wrapped: partial(wrapper, wrapped)
> 
> >>
> 
> >> ...
> 
> >>
> 
> >> py> @make_wrapper
> 
> >>
> 
> >> ... def simple_decorator(func, *args, **kwargs):
> 
> >>
> 
> >> ... print "Entering decorated function"
> 
> >>
> 
> >> ... result = func(*args, **kwargs)
> 
> >>
> 
> >> ... print "Exiting decorated function"
> 
> >>
> 
> >> ... return result
> 
> >>
> 
> >> ...
> 
> >>
> 
> >> py> @simple_decorator
> 
> >>
> 
> >> ... def my_function(a, b, c):
> 
> >>
> 
> >> ... """Doc string"""
> 
> >>
> 
> >> ... return a+b+c
> 
> >>
> 
> >> ...
> 
> >>
> 
> >> py> my_function(1, 2, 3)
> 
> >>
> 
> >> Entering decorated function
> 
> >>
> 
> >> Exiting decorated function
> 
> >>
> 
> >> 6
> 
> >>
> 
> >>
> 
> >>
> 
> >> So to me, this is far more magical than nested functions. If I saw this
> 
> >>
> 
> >> in t requires me to hunt through your library for the "simple function
> 
> >>
> 
> >> buried in a utility module somewhere" (your words), instead of seeing
> 
> >>
> 
> >> everything needed in a single decorator factory function. It requires
> 
> >>
> 
> >> that I understand how partial works, which in my opinion is quite tricky.
> 
> >>
> 
> >> (I never remember how it works or which arguments get curried.)
> 
> >>
> 
> >>
> 
> >>
> 
> >> And the end result is that the decorated function is less debugging-
> 
> >>
> 
> >> friendly than I demand: it is an anonymous partial object instead of a
> 
> >>
> 
> >> named function, and the doc string is lost. And it is far from clear to
> 
> >>
> 
> >> me how to modify your recipe to use functools.wraps in order to keep the
> 
> >>
> 
> >> name and docstring, or even whether I *can* use functools.wraps.
> 
> >>
> 
> >>
> 
> >>
> 
> >> I dare say I could answer all those questions with some experimentation
> 
> >>
> 
> >> and research. But I don't think that your "metadecorator" using partial
> 
> >>
> 
> >> is *inherently* more understandable than the standard decorator approach:
> 
> >>
> 
> >>
> 
> >>
> 
> >> def simple_decorator2(func):
> 
> >>
> 
> >> @functools.wraps(func)
> 
> >>
> 
> >> def inner(*args, **kwargs):
> 
> >>
> 
> >> print "Entering decorated function"
> 
> >>
> 
> >> result = func(*args, **kwargs)
> 
> >>
> 
> >> print "Exiting decorated function"
> 
> >>
> 
> >> return result
> 
> >>
> 
> >> return inner
> 
> >>
> 
> >>
> 
> >>
> 
> >> This is no more complex than yours, and it keeps the function name and
> 
> >>
> 
> >> docstring.
> 
> >>
> 
> >>
> 
> >>
> 
> >>
> 
> >>
> 
> >> > Parameterized decorators are not much more
> 
> >>
> 
> >> > difficult this way.  This function:
> 
> >>
> 
> >> [snip code]
> 
> >>
> 
> >> > And now we have a fancy parameterized decorator that again requires no
> 
> >>
> 
> >> > thinking about nested functions at all.
> 
> >>
> 
> >>
> 
> >>
> 
> >> Again, at the cost of throwing away the function name and docstring.
> 
> >>
> 
> >>
> 
> >>
> 
> >> I realise that a lot of this boils down to personal preference, but I
> 
> >>
> 
> >> just don't think that nested functions are necessarily that hard to
> 
> >>
> 
> >> grasp, so I prefer to see as much of the decorator logic to be in one
> 
> >>
> 
> >> place (a nested decorator function) rather than scattered across two
> 
> >>
> 
> >> separate decorators plus partial.
> 
> 
> 
> Like chi fu, allow decorators to evolve upon themselves. Like simple
> 
> moves flow through water and allow memorization of activity through
> 
> evidence of existence.
> 
> 
> 
> 
> 
> -- 
> 
> Best Regards,


The concept of decorators is just a mapping from a function to another
function with the same name in python.


It should be easy to be grapsed for those studied real analysis and 
functional analysis.
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python garbage collector/memory manager behaving strangely

[88888 Dihedral]

alex23於 2012年9月17日星期一UTC+8上午11時25分06秒寫道：
> On Sep 17, 12:32 pm, "Jadhav, Alok" 
> 
> wrote:
> 
> > - As you have seen, the line separator is not '\n' but its '|\n'.
> 
> > Sometimes the data itself has '\n' characters in the middle of the line
> 
> > and only way to find true end of the line is that previous character
> 
> > should be a bar '|'. I was not able specify end of line using
> 
> > readlines() function, but I could do it using split() function.
> 
> > (One hack would be to readlines and combine them until I find '|\n'. is
> 
> > there a cleaner way to do this?)
> 
> 
> 
> You can use a generator to take care of your readlines requirements:
> 
> 
> 
> def readlines(f):
> 
> lines = []
> 
> while "f is not empty":
> 
> line = f.readline()
> 
> if not line: break
> 
> if len(line) > 2 and line[-2:] == '|\n':
> 
> lines.append(line)
> 
> yield ''.join(lines)
> 
> lines = []
> 
> else:
> 
> lines.append(line)
> 
> 
> 
> > - Reading whole file at once and processing line by line was must
> 
> > faster. Though speed is not of very important issue here but I think the
> 
> > tie it took to parse complete file was reduced to one third of original
> 
> > time.
> 
> 
> 
> With the readlines generator above, it'll read lines from the file
> 
> until it has a complete "line" by your requirement, at which point
> 
> it'll yield it. If you don't need the entire file in memory for the
> 
> end result, you'll be able to process each "line" one at a time and
> 
> perform whatever you need against it before asking for the next.
> 
> 
> 
> with open(u'infile.txt','r') as infile:
> 
> for line in readlines(infile):
> 
> ...
> 
> 
> 
> Generators are a very efficient way of processing large amounts of
> 
> data. You can chain them together very easily:
> 
> 
> 
> real_lines = readlines(infile)
> 
> marker_lines = (l for l in real_lines if l.startswith('#'))
> 
> every_second_marker = (l for i,l in enumerate(marker_lines) if (i
> 
> +1) % 2 == 0)
> 
> map(some_function, every_second_marker)
> 
> 
> 
> The real_lines generator returns your definition of a line. The
> 
> marker_lines generator filters out everything that doesn't start with
> 
> #, while every_second_marker returns only half of those. (Yes, these
> 
> could all be written as a single generator, but this is very useful
> 
> for more complex pipelines).
> 
> 
> 
> The big advantage of this approach is that nothing is read from the
> 
> file into memory until map is called, and given the way they're
> 
> chained together, only one of your lines should be in memory at any
> 
> given time.

The basic problem is whether the output items really need 
all lines of the input text file to be buffered to 
produce the results.


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

Re: Decorators not worth the effort

[88888 Dihedral]

Chris Angelico於 2012年9月18日星期二UTC+8下午9時25分04秒寫道：
> On Tue, Sep 18, 2012 at 11:19 PM, Neil Cerutti  wrote:
> 
> > On 2012-09-14, Chris Angelico  wrote:
> 
> >> But then again, who actually ever needs fibonacci numbers?
> 
> >
> 
> > If it should happen that your question is not facetious:
> 
> >
> 
> > http://en.wikipedia.org/wiki/Fibonacci_number#Applications
> 
> 
> 
> It wasn't entirely facetious. I know there are a few cases where
> 
> they're needed, but I think they're calculated far more often to
> 
> demonstrate algorithms than because you actually have use of them. :)
> 
> 
> 
> Though it's as well to mention these sorts of things now and then. I
> 
> remember one time writing up something or other, and my dad was
> 
> looking over my shoulder and asked me why I'd written a little
> 
> Pascal's Triangle generator. He didn't know that it had direct
> 
> application to whatever-it-was. And unfortunately I don't remember
> 
> what I was even writing at the time :)
> 
> 
> 
> ChrisA

I would suggest one should solve the Fibnaci(5) first and fast in Python.

Then one can think about computing c(n,k) in Python for large n.


Then
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Decorators not worth the effort

[88888 Dihedral]

Terry Reedy於 2012年9月15日星期六UTC+8上午4時40分32秒寫道：
> 2nd try, hit send button by mistake before
> 
> 
> 
> On 9/14/2012 5:28 AM, Jean-Michel Pichavant wrote:
> 
> 
> 
> > Decorators are very popular so I kinda already know that the fault is
> 
> > mine. Now to the reason why I have troubles writing them, I don't
> 
> > know. Every time I did use decorators, I spent way too much time
> 
> > writing it (and debugging it).
> 
> 
> 
> You are writing parameterized decorators, which require inverted 
> 
> currying of the wrapper maker. Perhaps that is why you have trouble. As 
> 
> I showed in response to Cameron, it may be easier to avoid that by using 
> 
> a traditional post-def wrapping call instead of decorator syntax.
> 
> 
>  
> -- 
> 
> Terry Jan Reedy

I'll give another example to show the decorators in python in
versions above 2.4 .

# a general function with the variable input : def  fname( *argc,  **argn)
# a deco is a mapping from an input  funtion to another  function

def deco( fn, *list_in, **dict_in): # use list_in and dict_in to modify fn
""" deco wrapper """ # deco.__doc__ 

#print list_in, dict_in, " in the deco"
 
def wrapper( fn, *argc, **argan): # to be returned as a function
   # do things one wants before calling fn 
   result=fn(*argc, **argn)  # call the original, save the result
   # do things after calling fn   
   return result 
# enhance the  wrapper and get info of fn
wrapper.__doc__=fn.__doc__
# enhance wrapper with result, fn, list_in, dict_in
#
 return wrapper

def f1():
   """ doc of f1"""
   print "inside f1"

f2=deco(f1, 2,3,4,5,6, MSG="deco f1 to f2")

f2() # invoke the decorated function from f1


# For a deco maps a deco to another deco  can be done similarly


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

Re: Python presentations

[88888 Dihedral]

andrea crotti於 2012年9月20日星期四UTC+8上午12時42分50秒寫道：
> 2012/9/19 Trent Nelson :
> 
> >
> 
> > FWIW, I gave a presentation on decorators to the New York Python
> 
> > User Group back in 2008.  Relevant blog post:
> 
> >
> 
> > http://blogs.onresolve.com/?p=48
> 
> >
> 
> > There's a link to the PowerPoint presentation I used in the first
> 
> > paragraph.  It's in .pptx format; let me know if you'd like it in
> 
> > some other form.
> 
> >
> 
> > Regards,
> 
> >
> 
> > Trent.
> 
> 
> 
> 
> 
> Ok thanks a lot, how long did it take for you to present that material?
> 
> 
> 
> Interesting the part about the learning process, I had a similar
> 
> experience, but probably skip this since I only have 30 minutes.
> 
> 
> 
> Another thing which I would skip or only explain how it works are
> 
> parametrized decorators, in the triple-def form they just look to ugly
> 
> to be worth the effort (but at least should be understood).

I think the decorator part is reasonable in testing and prototyping.

Every layor of some decorator just adds more overheads, therefore, 
the syntax sugar of the symbol @ just reminds the programmer the fact.

Acctually writing better wrappers for non-trivial enhancements
to objects or functions should be practiced by professionals.

It is easy to import objects written by others in python. 

It is also user responsible to test and enhance the objects 
from others by decorators, the unittest module, or whatever suitable.


I love to play with functions with a varable representing the time
in writing computer games that emulate  hundreds  to thousands of 
animated obects.









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

Re: Functional way to compare things inside a list

[88888 Dihedral]

Ulrich Eckhardt於 2012年9月21日星期五UTC+8下午5時15分03秒寫道：
> Am 21.09.2012 00:58, schrieb thorso...@lavabit.com:
> 
> > list = [{'1': []}, {'2': []}, {'3': ['4', '5']}]
> 
> >
> 
> > I want to check for a value (e.g. '4'), and get the key of the dictionary
> 
> > that contains that value.
> 
> 
> 
> Note:
> 
> 1. list is a built-in type, who's name is rebound above
> 
> 2. The list above contains dictionaries that all only contain a single key?
> 
> 3. You have strings containing decimal representations of numbers?
> 
> 
> 
>  > (Yep, this is bizarre.)
> 
> 
> 
> The data are really stored in a strange way and you might be able to 
> 
> make things clearer by reorganizing them a bit.
> 
> 
> 
> 
> 
> > some_magic(list, '4')
> 
> > => '3'
> 
> >
> 
> > What's the functional way to do it?
> 
> 
> 
> Functional as in functional programming and an emphasis on lazy 
> 
> evaluation? In that case I'd write a generator that emits the keys where 
> 
> the values contain the requested string.
> 
> 
> 
> 
> 
> > Is it possible to do it with a one-liner?
> 
> 
> 
> Yep, filter(), lambda and the 'in' operator. Question remains if this is 
> 
> readable. Note that you can use a local function, too, if you just want 
> 
> to reduce the scope/visibility.
> 
> 
> 
> 
> 
> Good luck!
> 
> 
> 
> 
> 
> Uli

I don't think functional aspects are only marked as lazy
programming. 

It just means when one is experimenting something 
the efficient execution in speed is not on focus 
yet. 

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

Re: [Q] How to exec code object with local variables specified?

[88888 Dihedral]

Makoto Kuwata於 2012年9月20日星期四UTC+8下午7時27分40秒寫道：
> Hi,
> 
> 
> 
> Is it possible to run code object with local variables specified?
> 
> I'm trying the following code but not work:
> 
> 
> 
> def fn():
> 
>x = 1
> 
>y = 2
> 
> localvars = {'x': 0}
> 
> exec(fn.func_code, globals(), localvars)
> 
> print(localvars)
> 
> ## what I expected is: {'x': 1, 'y': 2}
> 
> ## but actual is:  {'x': 0}
> 
> 
> 
> Python: 2.7.3
> 
> OS: MacOS X
> 
> 
> 
> --
> 
> regards,
> 
> makoto kuwata

Do you plan to write an IDE for python scrits ?

I have seen a lot abusiosns of spawns or pipes of mutlti-processes, 
and now the exec part again.

I think the sources of Doctor Python and IDLE were available 
years ago for showing off python's capabilities in developing an IDE.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Functional way to compare things inside a list

[88888 Dihedral]

A

Ian於 2012年9月22日星期六UTC+8上午4時50分49秒寫道：
> On Fri, Sep 21, 2012 at 1:54 PM, 88888 Dihedral
> 
>  wrote:
> 
> > I don't think functional aspects are only marked as lazy
> 
> > programming.
> 
> 
> 
> He wrote "lazy evaluation", not "lazy programming".  Two entirely
> 
> different things.
> 
> 
> 
> > It just means when one is experimenting something
> 
> > the efficient execution in speed is not on focus
> 
> > yet.
> 
> 
> 
> No, what you're describing is a "prototype".  It has nothing to do
> 
> with functional programming at all.

A function with varaible arguments can be stored as a variable
to functions called decorators in python to return  enhanced functions.

A function mapps a decorator to another decorator can be called 
a decorator map or a decorator maker in python.

The closure level is guaranteed for decorators to be mapped by 
multi-levels of decorator mappers trivially in python.

What do you want else for functional prgramming in python?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: technologies synergistic with Python

[88888 Dihedral]

i

Rodrick Brown於 2012年9月22日星期六UTC+8上午6時33分59秒寫道：
> On Sep 21, 2012, at 5:59 PM, Ethan Furman  wrote:
> 
> 
> 
> > Greetings!
> 
> > 
> 
> > What is the consensus... okay, okay -- what are some wide ranging opinions 
> > on technologies that I should know if my dream job is one that consists 
> > mostly of Python, and might allow telecommuting?
> 
> > 
> 
> > (Please don't say Java, please don't say Java, please don't say... ;)
> 
> 
> 
> Django, JavaScript, HTML 5, JQuery, , SQL, Redis, Twisted
> 
> 
> 
> > 
> 
> > ~Ethan~
> 
> > -- 
> 
> > http://mail.python.org/mailman/listinfo/python-list
 
I always prefer a computer language with a lot examples in the 
sources for all kinds of  nontrivial applications.

I am not interested in those trivial batches or shell programming
scripts for novices.






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

Re: Functional way to compare things inside a list

[88888 Dihedral]

Ian於 2012年9月22日星期六UTC+8下午2時23分43秒寫道：
> On Fri, Sep 21, 2012 at 7:25 PM, Steven D'Aprano
> 
>  wrote:
> 
> > On Fri, 21 Sep 2012 14:49:55 -0600, Ian Kelly wrote:
> 
> >
> 
> >> On Fri, Sep 21, 2012 at 1:54 PM, 8 Dihedral
> 
> >>  wrote:
> 
> >>> I don't think functional aspects are only marked as lazy programming.
> 
> >>
> 
> >> He wrote "lazy evaluation", not "lazy programming".  Two entirely
> 
> >> different things.
> 
> >
> 
> >
> 
> > For the record, the consensus here is that 8 Dihedral is probably a
> 
> > bot. It appears to be a pretty good bot, I haven't spotted it making any
> 
> > egregious or obvious grammatical mistakes, but the semantics of its posts
> 
> > don't seem quite human.
> 
> 
> 
> I'm aware of that, although sometimes the posts seem coherent enough
> 
> that I think maybe it's not.  Especially the ones where it posts
> 
> almost-working code snippets, complete with obvious typos.
> 
> 
> 
> Then it posts a complete non sequitur like the reply to my reply in
> 
> this thread, and the illusion is shattered.

Do you want to use the lisp way for implementing functional programming?

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

Re: Blue Screen Python

[88888 Dihedral]

Dave Angel於 2012年9月22日星期六UTC+8下午7時44分54秒寫道：
> On 09/22/2012 06:53 AM, Alister wrote:
> 
> > On Fri, 21 Sep 2012 18:47:57 -0400, Dave Angel wrote:
> 
> >
> 
> >> 
> 
> >>
> 
> >> That's not true at all.  You'd re thinking of Windows 3, Windows 95, 98,
> 
> >> and ME, which were hacked on top of MSDOS.  But Windows NT3.5, 4, 2000,
> 
> >> XP, Vista and Windows 7 have an entirely different bloodline.
> 
> >>
> 
> >> NT 3.51 was actually very robust, but in 4.0 to gain better performance,
> 
> >> they apparently did some compromising in the video driver's isolation.
> 
> >> And who knows what's happened since then.
> 
> > Although NT upwards has tried to introduce
> 
> 
> 
> Your wording seems to imply that you still think NT was built on some
> 
> earlier MS product.  It was written from scratch by a team recruited
> 
> mostly from outside MS, including the leader, a guy who was I think
> 
> experienced in VMS development.  The names escape me right now.  But
> 
> there were a couple of books, by Helen someone, I think, which helped us
> 
> outsiders understand some of the philosophies of the development.
> 
> 
> 
> >  user-space requirements the 
> 
> > need to maintain backwards compatibility has compromised these efforts.
> 
> > it is not helped by the end user's (just look at what happened to Vista's 
> 
> > attempt to make users authorise any changes to the system)
> 
> >
> 
> >
> 
> I don't see any connection between memory address space user models and
> 
> user security models.
> 
> 
> 
> -- 
> 
> 
> 
> DaveA

I tested MS NT in 1998-2002. I was pleased by the results to run real
multi-tasking processes at that time. I ran some linux machines 
at that time, too.

Anyway the heap walker problems in all the unix and linux systems
were very obvious in those years. 

My conclusion at that time was people from DEC were really good in the OS.
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Blue Screen Python

[88888 Dihedral]

Chris Angelico於 2012年9月22日星期六UTC+8下午10時10分12秒寫道：
> On Sat, Sep 22, 2012 at 11:07 PM, Steven D'Aprano
> 
>  wrote:
> 
> > As per their partnership agreement, IBM took over development of OS/2
> 
> > version 2 while Microsoft worked on developing version 3. OS/2 2.0 was
> 
> > significantly improved over the 1.x series.
> 
> >
> 
> > Then Microsoft reneged on the agreement to release OS/2 version 3, and
> 
> > instead re-badged it as Windows NT. One might say there was a little bit
> 
> > of bad blood over this, especially as IBM had good reason to think that
> 
> > Microsoft had been spending IBM's money on NT.
> 
> 
> 
> And ever since then, Microsoft's been doing its best to kill OS/2 off.
> 
> By the look of the database server sitting next to me, and the clients
> 
> scattered throughout the building, it seems they have yet to
> 
> succeed...
> 
> 
> 
> OS/2 and Linux interoperate quite happily, too. Standards so .
> 
> 
> 
> ChrisA

This is off topic in this forum. But we are getting so far at the MMU part. 
A cpu with an L1 and  an L2  caches of large sizes is better to be
equipped with  a VMS like OS in the thread and the heap managements.


But if the situation is different, some other alternative approaches
might be more appropriate.


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

Re: write to a file two dict()

[88888 Dihedral]

giuseppe...@gmail.com於 2012年9月24日星期一UTC+8上午1時44分30秒寫道：
> Hi 
> 
> Have two dict() of the same length and i want print them to a common file.
> 
> 
> 
> 
> 
> a={1: 1, 2: 2, 3: 3}
> 
> b={1: 11, 2: 22, 3: 33}
> 
> 
> 
> in order to obtain 
> 
> 
> 
> 1 1 1 11
> 
> 2 2 2 22
> 
> 3 3 3 33
> 
> 
> 
> I tried 
> 
> 
> 
> output = open(dst_file, "w")
> 
> for (a), b , (c) , d in a.items() , b.items() :
> 
> output.write("%i %i %i %i\n" % (a,b,c,d))
> 
> output.close()
> 
> 
> 
> but i get the error ValueError: need more than 3 values to unpack.
> 
> 
> 
> do you have some suggestions?.
> 
> Thanks 
> 
> Giuseppe

You can pickle the object directly in python. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Does python have built command for package skeleton creation?

[88888 Dihedral]

xliiv於 2012年9月21日星期五UTC+8下午9時13分38秒寫道：
> On Friday, September 21, 2012 3:04:02 PM UTC+2, Tarek Ziadé wrote:
> 
> > On 9/21/12 2:14 PM, xliiv wrote:
> 
> > 
> 
> > >
> 
> > 
> 
> > > Python Paste is probably what you are looking for - see
> 
> > 
> 
> > >
> 
> > 
> 
> > > http://lucasmanual.com/mywiki/PythonPaste for example
> 
> > 
> 
> > > It's a nice beast but:
> 
> > 
> 
> > > - it's not built in. Should it be? I think it should.
> 
> > 
> 
> > You can suggest this to python-ideas but I really doubt you will get any 
> 
> > 
> 
> > traction. The sdtlib don't get new features these days because it's a burden
> 
> > 
> 
> > to maintain high level tool on a 2 years release cycle
> 
> 
> 
> Why is this '2 years release cycle'?

This is good in python to focus on comming HW patforms with 
varied parameters as the industry is advacing toward  all way 
to avoid a heavy landing of the IT and electronics industry.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Java singletonMap in Python

[88888 Dihedral]

Duncan Booth於 2012年9月25日星期二UTC+8上午1時33分31秒寫道：
> Steven D'Aprano  wrote:
> 
> 
> 
> > On Mon, 24 Sep 2012 00:14:23 +0100, Mark Lawrence wrote:
> 
> > 
> 
> >> Purely for fun I've been porting some code to Python and came across
> 
> >> the singletonMap[1].  I'm aware that there are loads of recipes on
> 
> >> the web for both singletons e.g.[2] and immutable dictionaries
> 
> >> e.g.[3].  I was wondering how to combine any of the recipes to
> 
> >> produce the best implementation, where to me best means cleanest and
> 
> >> hence most maintainable.  I then managed to muddy the waters for
> 
> >> myself by recalling the Alex Martelli Borg pattern[4].  Possibly or
> 
> >> even probably the latter is irrelevant, but I'm still curious to know
> 
> >> how you'd code this beast.
> 
> >> 
> 
> >> First prize for the best solution is a night out with me, no guesses
> 
> >> what the second prize is :)
> 
> >> 
> 
> >> [1]http://docs.oracle.com/javase/1.4.2/docs/api/java/util/
> 
> > Collections.html
> 
> > 
> 
> > Copied from that page:
> 
> > 
> 
> > "static Map singletonMap(Object key, Object value) 
> 
> > Returns an immutable map, mapping only the specified key to the
> 
> > specified value."
> 
> > 
> 
> > I don't see the point of this. It takes a single key, with a single 
> 
> > value, and is immutable so you can't change it or add new keys. What's
> 
> > the point? Why bother storing the key:value pair in a data structure, 
> 
> > then look up the same data structure to get the same value every time?
> 
> > 
> 
> > # Pseudo-code
> 
> > d = singletonMap(key, calculate(key))
> 
> > # later:
> 
> > value = d[key]  # there's only one key this could be
> 
> > process(value)
> 
> > 
> 
> > 
> 
> > Why not just store the value, instead of key, value and mapping?
> 
> > 
> 
> > value = calculate(key)
> 
> > # later
> 
> > process(value)
> 
> > 
> 
> > 
> 
> > 
> 
> Google is your friend. Searching for "java singletonMap" gives this as
> 
> the second hit:
> 
> 
> 
> http://stackoverflow.com/questions/7125536/when-would-i-use-java-collections-singletonmap-method
> 
> 
> 
> The answers seem to be that it's for all those cases in Java where you have a 
> 
> method that takes a map as an argument and you want to pass in a map with a 
> single
> 
> kep/value pair. In that case it lets you replace 3 lines of Java with 1.
> 
> 
> 
> e.g. from the comments:
> 
> "If you have a simple select statement like "select foo from bar where id = 
> :barId" 
> 
> then you would need a parameter map with a single key-value pair, barId=123. 
> 
> That's a great place to use singletonMap()"
> 
> 
> 
> Of course in Python you just use a dict literal in that case so it's 
> pointless.
> 
> 
> 
> -- 
> 
> Duncan Booth http://kupuguy.blogspot.com

Cheers to those who are programmers that really love  authoring in the high 
level one with tools to translate into other computer languages,
and also collecting  the upgrade fees from clients.


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

Re: How to limit CPU usage in Python

[88888 Dihedral]

DPalao於 2012年9月25日星期二UTC+8下午11時13分54秒寫道：
> On Jueves septiembre 20 2012 11:12:44 Rolando Cañer Roblejo escribió:
> 
> > Hi all,
> 
> > 
> 
> > Is it possible for me to put a limit in the amount of processor usage (%
> 
> > CPU) that my current python script is using? Is there any module useful
> 
> > for this task? I saw Resource module but I think it is not the module I
> 
> > am looking for. Some people recommend to use nice and cpulimit unix
> 
> > tools, but those are external to python and I prefer a python solution.
> 
> > I am working with Linux (Ubuntu 10.04).
> 
> > 
> 
> > Best regards.
> 
> 
> 
> Hola,
> 
> Sometimes a stupid solution like the following does the trick:
> 
> 
> 
> > import time
> 
> > for t in tasks:
> 
> > do_something(t)
> 
> > time.sleep(some_seconds)
> 
> 
> 
> where "some_seconds" is a number related to the typical time-scale of the 
> 
> tasks you are doing.
> 
> 
> 
> Hope it helps,
> 
> 
> 
> Regards
> 
> 
> 
> 
> 
> -- 
> 
> Miller's Slogan:
> 
>   Lose a few, lose a few.

I think I'll prefer to use a generator of my object in python
to replace the sleep from the unix world. The reason is that I am not paid 
from selling or buying  work-stations in some business unit directly and 
immediately.


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

Re: Article on the future of Python

[88888 Dihedral]

Grant Edwards於 2012年9月26日星期三UTC+8上午2時25分31秒寫道：
> On 2012-09-25, Martin P. Hellwig  wrote:
> 
> > On Tuesday, 25 September 2012 09:14:27 UTC+1, Mark Lawrence  wrote:
> 
> >> Hi all,
> 
> >> 
> 
> >> I though this might be of interest.
> 
> >> http://www.ironfroggy.com/software/i-am-worried-about-the-future-of-python
> 
> 
> 
> > I glanced over the article but it seems to me another 'I am afraid
> 
> > this is not the silver bullet I wanted it to be' article
> 
> 
> 
> Strange.  I didn't get that _at_all_ from the article.  
> 
> 
> 
> To me it was expressing concern about what happens when the range of
> 
> "niches" where Python is a good solution falls below a certain
> 
> critical mass -- will the "Python Community" start to stagnate because
> 
> it isn't attacting new developers in the quantity or diversity that it
> 
> used to...
> 
> 
> 
> -- 
> 
> Grant Edwards   grant.b.edwardsYow! Alright, you!!
> 
>   at   Imitate a WOUNDED SEAL
> 
>   gmail.compleading for a PARKING
> 
>SPACE!!
I don't think so in 201X. The uni-code support for users and clients 
all over the world should not be taxed by WINTEL only in 
multi-language support under the OS. I am glad to see a lot smart phones
or pads are fostering applications in various languages to help the IT
industry keeping  growing and expanding to those regeions covered 
by wirelees digital communications with devices priced in the range 
200 to 12000 usd.

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

Re: using "*" to make a list of lists with repeated (and independent) elements

[88888 Dihedral]

TP於 2012年9月27日星期四UTC+8上午5時25分04秒寫道：
> Hi everybody,
> 
> 
> 
> I have tried, naively, to do the following, so as to make lists quickly:
> 
> 
> 
> >>> a=[0]*2
> 
> >>> a
> 
> [0, 0]
> 
> >>> a[0]=3
> 
> >>> a
> 
> [3, 0]
> 
> 
> 
> All is working fine, so I extended the technique to do:
> 
> 
> 
> >>> a=[[0]*3]*2
> 
> >>> a
> 
> [[0, 0, 0], [0, 0, 0]]
> 
> >>> a[0][0]=2
> 
> >>> a
> 
> [[2, 0, 0], [2, 0, 0]]
> 
> 
> 
> The behavior is no more expected!
> 
> The reason is probably that in the first case, 0 is an integer, not a list, 
> 
> so Python copies two elements that are independent.
> 
> In the second case, the elements are [0,0,0], which is a list; when Python 
> 
> copies a list, he copies in fact the *pointer* to the list, such that we 
> 
> obtain this apparently strange behavior.
> 
> 
> 
> Is it the correct explanation?
> 
> In these conditions, how to make this list [[0,0,0],[0,0,0]] with "*" 
> 
> without this behavior?
> 
> 
> 
> Thanks,
> 
> 
> 
> TP

def zeros(m,n):
for i in xrange(m):
for j in xrange(n):
a[i][j]=0
return a

>>> a=zeros(3,2)
>>> a
[[0, 0, 0], [0, 0, 0], [0, 0, 0], [0, 0, 0]]
>>> 

I think this is what you want.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: using "*" to make a list of lists with repeated (and independent) elements

[88888 Dihedral]

Paul Rubin於 2012年9月27日星期四UTC+8上午5時43分58秒寫道：
> TP  writes:
> 
> > copies a list, he copies in fact the *pointer* to the list 
> 
> > Is it the correct explanation?
> 
> 
> 
> Yes, that is correct.
> 
> 
> 
> > In these conditions, how to make this list [[0,0,0],[0,0,0]] with "*" 
> 
> > without this behavior?
> 
> 
> 
> >>> a = [[0]*3 for i in xrange(2)]
> 
> >>> a[0][0]=2
> 
> >>> a
> 
> [[2, 0, 0], [0, 0, 0]]

I used numpy before. 

Python is not lisp but python can emulate the lisp behaviors.
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: using "*" to make a list of lists with repeated (and independent) elements

[88888 Dihedral]

8 Dihedral於 2012年9月27日星期四UTC+8上午6時07分35秒寫道：
> Paul Rubin於 2012年9月27日星期四UTC+8上午5時43分58秒寫道：
> 
> > TP  writes:
> 
> > 
> 
> > > copies a list, he copies in fact the *pointer* to the list 
> 
> > 
> 
> > > Is it the correct explanation?
> 
> > 
> 
> > 
> 
> > 
> 
> > Yes, that is correct.
> 
> > 
> 
> > 
> 
> > 
> 
> > > In these conditions, how to make this list [[0,0,0],[0,0,0]] with "*" 
> 
> > 
> 
> > > without this behavior?
> 
> > 
> 
> > 
> 
> > 
> 
> > >>> a = [[0]*3 for i in xrange(2)]
> 
> > 
> 
> > >>> a[0][0]=2
> 
> > 
> 
> > >>> a
> 
> > 
> 
> > [[2, 0, 0], [0, 0, 0]]
> 
> 
> 
> I used numpy before. 
> 
> 
> 
> Python is not lisp but python can emulate the lisp behaviors.

def zeros(m,n):
a=[]
for i in xrange(m):
a.append([0]*n)
return a

If  one wants to tranlate to C, this is the style.

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

Re: using "*" to make a list of lists with repeated (and independent) elements

[88888 Dihedral]

Tim Chase於 2012年9月27日星期四UTC+8上午6時44分42秒寫道：
> On 09/26/12 17:28, 88888 Dihedral wrote:
> 
> > 88888 Dihedral於 2012年9月27日星期四UTC+8上午6時07分35秒寫道：
> 
> >>>> In these conditions, how to make this list [[0,0,0],[0,0,0]] with "*" 
> 
> >>>> without this behavior?
> 
> >>> >>> a = [[0]*3 for i in xrange(2)]
> 
> >>> >>> a[0][0]=2
> 
> >>> >>> a
> 
> >>> [[2, 0, 0], [0, 0, 0]]
> 
> > 
> 
> > def zeros(m,n):
> 
> > a=[]
> 
> > for i in xrange(m):
> 
> > a.append([0]*n)
> 
> > return a
> 
> > 
> 
> > If  one wants to tranlate to C, this is the style.
> 
> 
> 
> But this is Python, so why the heck would anybody want to emulate
> 
> *C* style?  It could also be written in an assembly-language style,
> 
> COBOL style, or a Fortran style...none of which are particularly
> 
> valuable.
> 
> 
> 
> Besides, a C-style would allocate a single array of M*N slots and
> 
> then calculate 2d offsets into that single array. :-P
> 
> 
> 
> -tkc

I don't think a lot programmers can write assembly programs well
for different instruction sets of cpus.

Of course if GCC was not supportd in manny platforms free 
of charge, then I won't recommend this style of 
programming in python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Algorithms using Python?

[88888 Dihedral]

Wayne Werner於 2012年9月27日星期四UTC+8上午12時05分31秒寫道：
> On Fri, 21 Sep 2012, Dennis Lee Bieber wrote:
> 
> 
> 
> > On Fri, 21 Sep 2012 14:26:04 +0530, Mayuresh Kathe 
> 
> > declaimed the following in gmane.comp.python.general:
> 
> >
> 
> >> Is there a good book on foundational as well as advanced algorithms
> 
> >> using Python?
> 
> >>
> 
> > Depends on what you mean by "foundational"...
> 
> >
> 
> > Since Python has dynamic lists and dictionaries, I suspect you won't
> 
> > find any textbook focusing on linked-list or hashed lookup algorithms
> 
> > using Python.
> 
> >
> 
> > You can probably implement them, but they're not going to be very
> 
> > efficient. (And never "remove" an element from the linked-list
> 
> > implementation because Python would shift all the other elements, hence
> 
> > your "links" become invalid).
> 
> 
> 
> It's quite inefficient, but it would be fairly trivial to create a LL 
> 
> implementation like this:
> 
> 
> 
> class Link:
> 
>  def __init__(self):
> 
>  self.next = None
> 
>  self.value = None
> 
> 
> 
> class LinkedList:
> 
>  def __init__(self):
> 
>  self.head = None
> 
> 
> 
>  def add(self, value):
> 
>  node = Link()
> 
>  node.value = value
> 
>  self.append(node)
> 
> 
> 
>  def append(self, node):
> 
>  # Write some code
> 
> 
> 
> It's fairly easy to use reference types as one would use pointers in 
> 
> .
> 
> 
> 
> But it might actually require understanding pointers and such in the first 
> 
> place...
> 
> 
> 
> I'm not really aware of any algorithm that's impossible/harder to 
> 
> implement in Python - Python just makes most things a lot easier so you 
> 
> never have to deal with the lower level algorithms. Which makes *me* happy 
> 
> :)
> 
> 
> 
> -Wayne

In python  long integers of varried lengths of precesions, doubles, 
complex numbers,  immutable tuples, modifiable lists, modifiable dictionaries,
and functions and classes are all name resolved  basic built in types.


It is more interesting to implement a binary tree in python from 
a dictionary.

Also the set part can be implemented by long integers or dictionaries.

The symbolic computation part as in sympy is also a good example 
of high level programmings in python.

But this also means a lot kids will finish their calculous  homeworks 
trivially by machines instead of  reasoning and learning in person.





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

Re: using "*" to make a list of lists with repeated (and independent) elements

[88888 Dihedral]

Tim Chase於 2012年9月27日星期四UTC+8上午6時44分42秒寫道：
> On 09/26/12 17:28, 88888 Dihedral wrote:
> 
> > 88888 Dihedral於 2012年9月27日星期四UTC+8上午6時07分35秒寫道：
> 
> >>>> In these conditions, how to make this list [[0,0,0],[0,0,0]] with "*" 
> 
> >>>> without this behavior?
> 
> >>> >>> a = [[0]*3 for i in xrange(2)]
> 
> >>> >>> a[0][0]=2
> 
> >>> >>> a
> 
> >>> [[2, 0, 0], [0, 0, 0]]
> 
> > 
> 
> > def zeros(m,n):
> 
> > a=[]
> 
> > for i in xrange(m):
> 
> > a.append([0]*n)
> 
> > return a
> 
> > 
> 
> > If  one wants to tranlate to C, this is the style.
> 
> 
> 
> But this is Python, so why the heck would anybody want to emulate
> 
> *C* style?  It could also be written in an assembly-language style,
> 
> COBOL style, or a Fortran style...none of which are particularly
> 
> valuable.
> 
> 
> 
> Besides, a C-style would allocate a single array of M*N slots and
> 
> then calculate 2d offsets into that single array. :-P
> 
> 
> 
> -tkc

a=[1, 2,3] 
b=[a]*4
print b 
a[1]=4
print b

I thnik this is very clear about the situation in entangled references.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python source code easy to hack?

[88888 Dihedral]

Jayden於 2012年9月28日星期五UTC+8下午7時57分14秒寫道：
> Dear All,
> 
> 
> 
> I have a concern in developing commercial code with Python. Someone told me 
> that its program can be easily hacked to get its source code. Is it really 
> the case? Any way to protect your source code?
> 
> 
> 
> Thanks a lot!
> 
> 
> 
> Jayden

Nowadays high priced commercial IDE software products shipped  with a 
built in interpreter with some GUI to let users customize their own
needs in designs. This also means examples in source codes to 
be provided, too.

Anyway even compiled instructions can be iced and reverse engineered
for all the flows of the software.



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

Re: creating an artificial "last element" in sort list

[88888 Dihedral]

dave於 2012年9月29日星期六UTC+8上午7時51分10秒寫道：
> more clearer, this is a more realistic use case:
> 
> 
> 
> ['awefawef', 'awefawfsf', 'awefsdf', 'zz', 'zz', 
> 'zz']
> 
> 
> 
> and the quantity of ''zz'' would be dynamic.
> 
> 
> 
> On Friday, September 28, 2012 4:46:15 PM UTC-7, Ian wrote:
> 
> 
> 
> > 
> 
> > > a = ['a', 'b', x]
> 
> > 
> 
> > >
> 
> > 
> 
> > > b = sorted(a)
> 
> > 
> 
> > >
> 
> > 
> 
> > > What does x need to be to always be last on an ascending sort no matter 
> > > what 'a' and 'b' are within reason... I am expecting 'a' and 'b' will 
> > > be not longer than 10 char's long I tried making x = 
> > > '' and believe it or not, this appears FIRST on the 
> > > sort!!!
> 
> > 
> 
> > 
> 
> > 
> 
> > It appears last when I run the code.
> 
> > 
> 
> > 
> 
> > 
> 
> > To answer your question, though, if you want to force x to be last,
> 
> > 
> 
> > then I suggest removing it from the list and then appending it to the
> 
> > 
> 
> > end.

I am thinking if it is helpful to preprocess an arbitrary
list first into some set of unique  ordered elements before a sort. 

Anyway lists are passed by references  to functions in python. 

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

Re: using "*" to make a list of lists with repeated (and independent) elements

[88888 Dihedral]

On Saturday, September 29, 2012 9:46:22 PM UTC+8, Ramchandra Apte wrote:
> On Thursday, 27 September 2012 04:14:42 UTC+5:30, Tim Chase  wrote:
> 
> > On 09/26/12 17:28, 88888 Dihedral wrote:
> 
> > 
> 
> > > 8 Dihedral於 2012年9月27日星期四UTC+8上午6時07分35秒寫道：
> 
> > 
> 
> > >>>> In these conditions, how to make this list [[0,0,0],[0,0,0]] with "*" 
> 
> > 
> 
> > >>>> without this behavior?
> 
> > 
> 
> > >>> >>> a = [[0]*3 for i in xrange(2)]
> 
> > 
> 
> > >>> >>> a[0][0]=2
> 
> > 
> 
> > >>> >>> a
> 
> > 
> 
> > >>> [[2, 0, 0], [0, 0, 0]]
> 
> > 
> 
> > > 
> 
> > 
> 
> > > def zeros(m,n):
> 
> > 
> 
> > >   a=[]
> 
> > 
> 
> > >   for i in xrange(m):
> 
> > 
> 
> > >   a.append([0]*n)
> 
> > 
> 
> > >   return a
> 
> > 
> 
> > > 
> 
> > 
> 
> > > If  one wants to tranlate to C, this is the style.
> 
> > 
> 
> > 
> 
> > 
> 
> > But this is Python, so why the heck would anybody want to emulate
> 
> > 
> 
> > *C* style?  It could also be written in an assembly-language style,
> 
> > 
> 
> > COBOL style, or a Fortran style...none of which are particularly
> 
> > 
> 
> > valuable.
> 
> > 
> 
> > 
> 
> > 
> 
> > Besides, a C-style would allocate a single array of M*N slots and
> 
> > 
> 
> > then calculate 2d offsets into that single array. :-P
> 
> > 
> 
> > 
> 
> > 
> 
> > -tkc
> 
> 
> 
> 8 Dihedral is a bot.

Don't you get it why I avoided the lambda one liner as a functon. 

I prefer the def way with a name chosen.

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

Re: using "*" to make a list of lists with repeated (and independent) elements

[88888 Dihedral]

On Sunday, September 30, 2012 1:19:22 AM UTC+8, Ian wrote:
> On Sat, Sep 29, 2012 at 11:01 AM, 88888 Dihedral
> 
>  wrote:
> 
> >
> 
> > Don't you get it why I avoided the lambda one liner as a functon.
> 
> >
> 
> > I prefer the def way with a name chosen.
> 
> 
> 
> Certainly, but the Bresenham line algorithm is O(n), which is why it
> 
> is so superior to quicksort that is O(n log n).  Of course you might
> 
> try the Capo Ferro optimization, but I find that Thibault cancels out
> 
> Capo Ferro, don't you?

OK! I'll illustrate the lazy aspect of the python interpreter furthermore.

a=[1,2,3]
b=[a]*4 # different from a sliced copy as [list(a)]*4
print b
a[1]=4
print b
#-
a=666 # type morphed
print b 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Slicing iterables in sub-generators without loosing elements

[88888 Dihedral]

On Sunday, September 30, 2012 12:15:57 AM UTC+8, Thomas Bach wrote:
> Hi,
> 
> 
> 
> say we have the following:
> 
> 
> 
> >>> data = [('foo', 1), ('foo', 2), ('bar', 3), ('bar', 2)]
> 
> 
> 
> is there a way to code a function iter_in_blocks such that
> 
> 
> 
> >>> result = [ list(block) for block in iter_in_blocks(data) ]
> 
> 
> 
> evaluates to
> 
> 
> 
> >>> result = [ [('foo', 1), ('foo', 2)], [('bar', 3), ('bar', 2)] ]
> 
> 
> 
> by _only_ _iterating_ over the list (caching all the elements sharing
> 
> the same first element doesn't count)?
> 
> 
> 
> I came up with the following
> 
> 
> 
> def iter_in_blocks(iterable):
> 
> my_iter = iter(iterable)
> 
> while True:
> 
> first = next(my_iter)
> 
> pred = lambda entry: entry[0] == first[0]
> 
> def block_iter():
> 
> yield first
> 
> for entry in itertools.takewhile(pred, my_iter):
> 
> yield entry
> 
> yield block_iter()
> 
> 
> 
> which does not work as itertools.takewhile consumes the first entry
> 
> not fulfilling the pred.
> 
> 
> 
> I currently have the intuition that the problem is not solvable
> 
> without using e.g. a global to pass something back to iter_in_blocks
> 
> from block_iter. Any other suggestions?
> 
> 
> 
> Regards,
> 
>   Thomas Bach.

Your question seems vague to me. If you know you are storing 
only immutable tuples in a list, then the way to iterate is simple. 

For example: 

data = [('foo', 1), ('foo', 2), ('bar', 3), ('bar', 2)] 
# all tuples 

for item in data: 
x1=item[0] # first entry in each tuple
x2=item[1]
print x1, x2 # or use yield in a function to iterate



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

Re: parse an environment file

[88888 Dihedral]

On Monday, October 1, 2012 10:42:02 PM UTC+8, Chris Angelico wrote:
> On Tue, Oct 2, 2012 at 12:37 AM, Jason Friedman  wrote:
> 
> >> Is there a reason to use that format, rather than using Python
> 
> >> notation? I've at times made config files that simply get imported.
> 
> >> Instead of a dictionary, you'd have a module object:
> 
> >>
> 
> >>
> 
> >> # config.py
> 
> >> VAR1='foo'
> 
> >> VAR2='bar'
> 
> >> VAR3=VAR1+VAR2
> 
> >>
> 
> > There is a reason:  /path/to/export_file exists for Bash scripts, too,
> 
> > and I do not think I could get Bash to read config.py in the format
> 
> > stated above.  I want to maintain only one file.
> 
> 
> 
> (Responding on-list and hoping it was merely oversight that had that
> 
> email come to me personally)
> 
> 
> 
> Ah, fair enough. Well, since you're using the full range of bash
> 
> functionality, the only viable way to parse it is with bash itself.
> 
> I'd recommend going with the version you have above:
> 
> 
> 
> > * * * * * . /path/to/export_file && /path/to/script.py
> 
> 
> 
> Under what circumstances is this not an option? That'd be the next
> 
> thing to consider.
> 
> 
> 
> Alternatively, you may want to consider making your own config file
> 
> format. If you consciously restrict yourself to a severe subset of
> 
> bash functionality, you could easily parse it in Python - for
> 
> instance, always look for "export %s=%s" with simple strings for the
> 
> variable name and value.
> 
> 
> 
> ChrisA

I think one can ues some decorators to wrap OS  or platform 
dependent functions.

I am sure someone did that long time ago as the iron python
wrapped dot-net.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Slicing iterables in sub-generators without loosing elements

[88888 Dihedral]

On Monday, October 1, 2012 4:17:50 PM UTC+8, Mark Lawrence wrote:
> On 01/10/2012 01:58, 88888 Dihedral wrote:
> 
> >
> 
> > Your question seems vague to me. If you know you are storing
> 
> > only immutable tuples in a list, then the way to iterate is simple.
> 
> >
> 
> 
> 
> Does Python have a magic method that let's me use mutable tuples?  I'd 
> 
> also like immutable lists.  Is it worth raising a feature request on the 
> 
> bug tracker?
> 
> 
> 
> -- 
> 
> Cheers.
> 
> 
> 
> Mark Lawrence.

Python resolves objects by names and dynamical types.
This will force the programmer to write structured programs.



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

Re: Slicing iterables in sub-generators without loosing elements

[88888 Dihedral]

Steven D'Aprano於 2012年10月3日星期三UTC+8上午8時57分20秒寫道：
> On Wed, 03 Oct 2012 03:58:02 +1000, Chris Angelico wrote:
> 
> 
> 
> > Dihedral might be a bot and might not. I've come to the conclusion that
> 
> > it's not worth trying to find out, given that a good bot can outdo a lot
> 
> > of humans in useful conversation.
> 
> 
> 
> Oh, I'm convinced that it's a bot.
> 
> 
> 
> The fact that Dihedral never responds to conversations about him/it is a 
> 
> give away: nearly all people are far to egotistical to let accusations of 
> 
> bot-hood go unchallenged. And even though its responses are grammatically 
> 
> correct, they often are semantically meaningless. Even the best AIs 
> 
> (Evie, CleverBot, Alice) don't come close to passing the Turing test. It 
> 
> helps that Dihedral only talks about computer programming, but even so, 
> 
> it has well and truly failed my personal Turing test.
> 
> 
> 
> Mind you, some human beings fail the Turing test too:
> 
> 
> 
> http://northernplanets.blogspot.com.au/2006/06/failing-turing-test.html
> 
> 
> 
> 
> 
> Of course, Dihedral's creator wanted to really confound us, the 
> 
> occasional human response would probably muddy the waters sufficiently.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

Are you still not getting the generator part  in Python?
Do you really test any generator before?



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

Re: Slicing iterables in sub-generators without loosing elements

[88888 Dihedral]

Steven D'Aprano於 2012年10月3日星期三UTC+8上午9時24分13秒寫道：
> On Tue, 02 Oct 2012 18:11:20 -0700, 8 Dihedral wrote:
> 
> 
> 
> > Steven D'Aprano於 2012年10月3日星期三UTC+8上午8時57分20秒寫道：
> 
> 
> 
> >> Oh, I'm convinced that it's a bot.
> 
> >> The fact that Dihedral never responds to conversations about him/it is
> 
> >> a give away: nearly all people are far to egotistical to let
> 
> >> accusations of bot-hood go unchallenged.
> 
> [...]
> 
> >> Of course, Dihedral's creator wanted to really confound us, the
> 
> >> occasional human response would probably muddy the waters sufficiently.
> 
> 
> 
> > Are you still not getting the generator part  in Python? Do you really
> 
> > test any generator before?
> 
> 
> 
> I rest my case :)
> 
> 
> 
> I have many problems with generators. Can you tell me more about them? I 
> 
> really need your help. Sometimes, when it is very cold, the diesel 
> 
> freezes and the generator raises StopIteration at the wrong place.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven
Please work out your own templates  as I showed in the decorator part.

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

Re: Combinations of lists

[88888 Dihedral]

Oscar Benjamin於 2012年10月4日星期四UTC+8上午4時29分51秒寫道：
> Oscar wrote:
> 
> >>> def uniquecombinations(h, m):
> 
> >>> for ha in submultisets(h, len(h)//2):
> 
> >>> hb = list(h)
> 
> >>> for c in ha:
> 
> >>> hb.remove(c)
> 
> >>> yield [m[0] + a for a in ha] + [m[1] + b for b in hb]
> 
> >>>
> 
> >>> h = ['A', 'A', 'B', 'B']
> 
> >>> m = ['a', 'b']
> 
> >>>
> 
> >>> for x in uniquecombinations(h, m):
> 
> >>> print(x)
> 
> >>> '''
> 
> >>>
> 
> >>> Output:
> 
> >>> ['aB', 'aB', 'bA', 'bA']
> 
> >>> ['aA', 'aB', 'bA', 'bB']
> 
> >>> ['aA', 'aA', 'bB', 'bB']
> 
> 
> 
> On 3 October 2012 21:15, Steen Lysgaard  wrote:
> 
> > Hi,
> 
> >
> 
> > thanks for your interest. Sorry for not being completely clear, yes
> 
> > the length of m will always be half of the length of h.
> 
> >
> 
> > /Steen
> 
> 
> 
> Then you can make the uniquecombinations function recursive. First
> 
> find the elements that go with 'a' then from the remaining elements
> 
> find those that go with 'b', then 'c' and so on.
> 
> 
> 
> Oscar

Lets simplify the problem as follows:

A set of m symbols [0, 1,2,3...m-1] and each symbol can occur
a pecified number of times [(0, k(0)), (1, k(1)), (m-1, k(m-1)].rom a list 
to form a list of (i, k(i)) where  k(i) are  all positive integers.

For example [ (0,3), (1,2), (2, 1), (3, 2)], this is easy to generate 
valid numbers in base m numbers of sum(k(i)) digits.



in the final string.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Combinations of lists

[88888 Dihedral]

On Thursday, October 4, 2012 11:12:41 PM UTC+8, Steen Lysgaard wrote:
> 2012/10/4 Joshua Landau :
> 
> > On 3 October 2012 21:15, Steen Lysgaard  wrote:
> 
> >>
> 
> >> Hi,
> 
> >>
> 
> >> thanks for your interest. Sorry for not being completely clear, yes
> 
> >> the length of m will always be half of the length of h.
> 
> >
> 
> >
> 
> > (Please don't top post)
> 
> >
> 
> > I have a solution to this, then.
> 
> > It's not short or fast, but it's a lot faster than yours.
> 
> >
> 
> > But first let me explain the most obvious optimization to your version of
> 
> > the code:
> 
> >
> 
> >> combs = set()
> 
> >>
> 
> >>
> 
> >> for a in permutations(range(len(h)),len(h)):
> 
> >> comb = []
> 
> >> for i in range(len(h)):
> 
> >> comb.append(c[i][a[i]])
> 
> >> comb.sort()
> 
> >>
> 
> >> frzn = tuple(comb)
> 
> >> if frzn not in combs:
> 
> >> combs.add(frzn)
> 
> >
> 
> >
> 
> >  What I have done here is make your "combs" a set. This helps because you
> 
> > are searching inside it and that is an O(N) operation... for lists.
> 
> > A set can do the same in O(1). Simplez.
> 
> >
> 
> > first  = list("AABBCCDDEE")
> 
> > second = list("abcde")
> 
> > import itertools
> 
> > #
> 
> > # Generator, so ignoring case convention
> 
> > class force_unique_combinations:
> 
> > def __init__(self, lst, n):
> 
> > self.cache = set()
> 
> > self.internal_iter = itertools.combinations(lst, n)
> 
> > def __iter__(self):
> 
> > return self
> 
> > def __next__(self):
> 
> > while True:
> 
> > nxt = next(self.internal_iter)
> 
> > if not nxt in self.cache:
> 
> > self.cache.add(nxt)
> 
> > return nxt
> 
> > def combine(first, second):
> 
> > sletter = second[0]
> 
> > first_combinations = force_unique_combinations(first, 2)
> 
> > if len(second) == 1:
> 
> > for combination in first_combinations:
> 
> > yield [sletter+combination[0], sletter+combination[1]]
> 
> > else:
> 
> > for combination in first_combinations:
> 
> > first_ = first[:]
> 
> > first_.remove(combination[0])
> 
> > first_.remove(combination[1])
> 
> > prefix = [sletter+combination[0], sletter+combination[1]]
> 
> > for inner in combine(first_, second[1:]):
> 
> > yield prefix + inner
> 
> >
> 
> >
> 
> > This is quite naive, because I don't know how to properly implement
> 
> > force_unique_combinations, but it runs. I hope this is right. If you need
> 
> > significantly more speed your best chance is probably Cython or C, although
> 
> > I don't doubt 10x more speed may well be possible from within Python.
> 
> >
> 
> >
> 
> > Also, 8 Dihedral is a bot, or at least pretending like crazy to be one.
> 
> 
> 
> Great, I've now got a solution much faster than what I could come up with.
> 
> Thanks to the both of you.
> 
> And a good spot on 88... I could not for my life understand what he
> 
> (it) had written.
> 
> 
> 
> /Steen

If an unique order is defined, then it is trivial to solve this problem
without any recursions. 


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

Re: notmm is dead!

[88888 Dihedral]

Prasad, Ramit於 2012年10月6日星期六UTC+8上午4時06分31秒寫道：
> Steven D'Aprano wrote:
> 
> > Sent: Thursday, October 04, 2012 7:22 PM
> 
> > To: python-list@python.org
> 
> > Subject: Re: notmm is dead!
> 
> > 
> 
> > On Thu, 04 Oct 2012 14:10:46 -0400, Etienne Robillard wrote:
> 
> > 
> 
> > > Dear list,
> 
> > >
> 
> > > Due to lack of energy and resources i'm really sad to announce the
> 
> > > removal of notmm from pypi and bitbucket.
> 
> > 
> 
> > Well that's just rude. Even if you don't intend to maintain the software
> 
> > any more, why are you removing it from pypi? Since you say you are a fan
> 
> > of Open Source software, just flag it as unmaintained and leave it for
> 
> > somebody else to pick up.
> 
> > 
> 
> > If you are going to abandon the project, release it on PyPI with a dual
> 
> > MIT and GPL licence, and let it be taken over by somebody else.
> 
> > 
> 
> > If you were looking for sympathy here, starting off by removing your
> 
> > project from free hosting, then complaining that you can't pay for the
> 
> > non-free hosting, was NOT the right way to do so.
> 
> 
> 
> I might be misunderstanding, but I think Etienne wants money in 
> 
> exchange for letting someone else take over. 
> 
> 
> 
> > 
> 
> > By the way, the latest version of notmm (0.4.4) has an empty licence
> 
> > file. No licence means that everyone using it is unlicenced and therefore
> 
> > infringing your copyright.
> 
> > 
> 
> > 
> 
> 
> 
> 
> 
> This email is confidential and subject to important disclaimers and
> 
> conditions including on offers for the purchase or sale of
> 
> securities, accuracy and completeness of information, viruses,
> 
> confidentiality, legal privilege, and legal entity disclaimers,
> 
> available at http://www.jpmorgan.com/pages/disclosures/email.

I think it is OK to have some string attatched in those open source projects.

Nowadays the software industry is just like the perfume and prtinting 
and the audio-video entaertainment   industry.

The replication cost is so  low. Don't forget the lawsuites in Facebook 
about  the participants charged the founder in the courts.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: write binary with struct.pack_into

[88888 Dihedral]

palmeira於 2012年10月6日星期六UTC+8上午11時27分47秒寫道：
> Dear pythonists,
> 
> 
> 
> I'm having a problem with read/write binary in python.
> 
> I have a binary file that I need to read information, extract a array,
> 
> modify this array and put these values into file again in same binary
> 
> format.
> 
> I need to use unpack_from and pack_into because sometimes gonna need
> 
> read/write in the middle of file.
> 
> 
> 
> Script:
> 
> 
> 
> import struct
> 
> bloco='>%df' %(252)  #Binary format
> 
> 
> 
> # READ
> 
> fa=open('testIN.bin')
> 
> my_array=struct.unpack_from(bloco,fa.read()[0*4:251*4])# my_aray = 252
> 
> elements array
> 
> ## This read is OK!
> 
> 
> 
> #WRITE
> 
> fb=open('testOUT.bin')
> 
> test=struct.pack_into(bloco,fb.write()[0*4:251*4])  # ERROR in this WRITE
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Regards,
> 
> 
> 
> Ronaldo Palmeira.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> 
> View this message in context: 
> http://python.6.n6.nabble.com/write-binary-with-struct-pack-into-tp4991234.html
> 
> Sent from the Python - python-list mailing list archive at Nabble.com.

Are you writing and reading files produce by different 
languages?

The pickle part  is better  for OOP and glue logics in python.

The heavy computing part should be done in CYTHON.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problems building Python from hg trunk on Open SUSE

[88888 Dihedral]

Skip Montanaro於 2012年10月6日星期六UTC+8上午8時25分06秒寫道：
> I haven't messed around with Python 3 recently, so decided to give it
> 
> a whirl again.  I cloned the trunk (cpython) and set about it.  This
> 
> is on an OpenSUSE 12.1 system.  I configured like so:
> 
> 
> 
>   ./configure --prefix=/home/skipm/.linux-local
> 
> 
> 
> and ran the usual "make ; make install".
> 
> 
> 
> I'm a bit perplexed about how it is installed.  Instead of installing
> 
> shared objects in
> 
> 
> 
>   /home/skipm/.linux-local/lib/python3.4/lib-dynload
> 
> 
> 
> they were installed in
> 
> 
> 
> /home/skipm/.linux-local/lib64/python3.4/lib-dynload
> 
> 
> 
> (note the "lib64" vs. "lib").  This would be fine, except sys.path
> 
> doesn't include the "lib64" version of this path:
> 
> 
> 
> % PYTHONPATH= PYTHONSTARTUP= ~/.linux-local/bin/python3.4 -S
> 
> Could not find platform dependent libraries 
> 
> Consider setting $PYTHONHOME to [:]
> 
> Python 3.4.0a0 (default:26200f535296, Oct  3 2012, 12:48:07)
> 
> [GCC 4.4.6 [TWW]] on linux
> 
> >>> import sys
> 
> >>> sys.path
> 
> ['', '', '/home/skipm/.linux-local/lib/python34.zip',
> 
> '/home/skipm/.linux-local/lib/python3.4/',
> 
> '/home/skipm/.linux-local/lib/python3.4/plat-linux',
> 
> '/home/skipm/.linux-local/lib/lib-dynload']
> 
> 
> 
> I see the message about setting PYTHONHOME.  (That happens to be bad
> 
> advice as sys.prefix and sys.exec_prefix are identical in this case.)
> 
> What I don't understand is why directories containing "lib64" are not
> 
> in sys.path by default, given that that's where "make install" put
> 
> things.
> 
> 
> 
> GCC is as delivered by The Written Word.  (This is a work computer.
> 
> The powers that be settled on TWW awhile ago for packaging all open
> 
> source software we use on Linux and Solaris, thus removing a headache
> 
> from our support staff.)  It is:
> 
> 
> 
> % gcc --version
> 
> gcc (GCC) 4.4.6 [TWW]
> 
> Copyright (C) 2010 Free Software Foundation, Inc.
> 
> This is free software; see the source for copying conditions.  There is NO
> 
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> 
> The architecture looks like this:
> 
> 
> 
> % uname -a
> 
> Linux udesktop264 3.1.0-1.2-desktop #1 SMP PREEMPT Thu Nov 3 14:45:45
> 
> UTC 2011 (187dde0) x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> 
> I don't see anything in the output of "./configure --help" which
> 
> relates to 64-bit install directories, though I do see some lines in
> 
> config.log about guessing the architecture.  Some cursory googling
> 
> didn't turn up any promising web pages, and I didn't find anything in
> 
> the various documentation files in the repo related to building
> 
> Python.
> 
> 
> 
> Any suggestions about how to resolve this would be appreciated.
> 
> 
> 
> Thx,
> 
> 
> 
> Skip

I am waiting for JYTHON and IRON PYTHON to be upgraded.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Private methods

[88888 Dihedral]

D.M. Procida於 2012年10月9日星期二UTC+8下午9時24分30秒寫道：
> What exactly is the point of a private method? Why or when would I want
> 

Private methods in the object level are searched first 
in the run time of python interpreter. 

I did turn some private methods in to c programs from time to time.

 
 

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

Re: Checking for dlls in ctypes

[88888 Dihedral]

Wanderer於 2012年10月12日星期五UTC+8下午11時36分27秒寫道：
> I'm trying to write some code that will load one of three dll depending on 
> the one available. I've tried the code below, but it doesn't work. The try 
> except doesn't catch the exception. Is there a way to do this?
> 
> 
> 
> try:
> 
> self.dll = windll.pvcam64
> 
> except:
> 
> print "No pvcam64"
> 
> try:
> 
> self.dll = windll.pvcam32
> 
> except:
> 
> print "No pvcam32"
> 
> try:
> 
> self.dll = windll.pvcam
> 
> except:
> 
> print "No pvcam"
> 
> return
> 
> else:
> 
> print "installed pvcam"
> 
> else:
> 
> print "installed pvcam32"
> 
> else:
> 
> print "installed pvcam64"

In linux  there are shared libraries that could be linked in the runtime.

But for the security concerns this requres the system administrator account 
to install shared libraries.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: overriding equals operation

[88888 Dihedral]

Pradipto Banerjee於 2012年10月16日星期二UTC+8下午9時59分05秒寫道：
> I am trying to define class, where if I use a statement a = b, then instead 
> of "a" pointing to the same instance as "b", it should point to a copy of 
> "b", but I can't get it right.
> 
> 
> 
> Currently, I have the following:
> 
> 
> 
> 
> 
> 
> 
> class myclass(object):
> 
> def __init__(self, name='')
> 
> self.name = name
> 
> 
> 
> def copy(self):
> 
> newvar = myclass(self.name)
> 
> return newvar
> 
> 
> 
> def __eq__(self, other):
> 
> if instance(other, myclass):
> 
> return self == other.copy()
> 
> return NotImplemented
> 
> 
> 
> 
> 
> Now if I try:
> 
> 
> 
> >>> a=myclass()
> 
> >>> a.name = 'test'
> 
> >>> b=a
> 
What you really want is b=a.copy() 
not b=a to disentangle two objects.

__eq__ is used in the comparison operation. 
 


> >>> b.name
> 
> 'test'
> 
> >>> b.name = 'test2'
> 
> >>> a.name
> 
> 'test2'
> 
> 
> 
> I wanted b=a to make a new copy of "a", but then when I assigned b.name = 
> 'test2', even a.name became 'test2'.
> 
> 
> 
> How can I rectify my code to make the __eq__() behave like copy()?
> 
> 
> 
> Thanks
> 
> 
> 
> 
> 
>  This communication is for informational purposes only. It is not intended to 
> be, nor should it be construed or used as, financial, legal, tax or 
> investment advice or an offer to sell, or a solicitation of any offer to buy, 
> an interest in any fund advised by Ada Investment Management LP, the 
> Investment advisor.  Any offer or solicitation of an investment in any of the 
> Funds may be made only by delivery of such Funds confidential offering 
> materials to authorized prospective investors.  An investment in any of the 
> Funds is not suitable for all investors.  No representation is made that the 
> Funds will or are likely to achieve their objectives, or that any investor 
> will or is likely to achieve results comparable to those shown, or will make 
> any profit at all or will be able to avoid incurring substantial losses.  
> Performance results are net of applicable fees, are unaudited and reflect 
> reinvestment of income and profits.  Past performance is no guarantee of 
> future results. All financial data and other information are not warranted as 
> to completeness or accuracy and are subject to change without notice.
> 
> 
> 
> Any comments or statements made herein do not necessarily reflect those of 
> Ada Investment Management LP and its affiliates. This transmission may 
> contain information that is confidential, legally privileged, and/or exempt 
> from disclosure under applicable law. If you are not the intended recipient, 
> you are hereby notified that any disclosure, copying, distribution, or use of 
> the information contained herein (including any reliance thereon) is strictly 
> prohibited. If you received this transmission in error, please immediately 
> contact the sender and destroy the material in its entirety, whether in 
> electronic or hard copy format.

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

Re: list comprehension question

[88888 Dihedral]

Dave Angel於 2012年10月17日星期三UTC+8下午10時37分01秒寫道：
> On 10/17/2012 10:06 AM, rusi wrote:
> 
> > On Oct 17, 5:33 pm, Dave Angel  wrote:
> 
> >> On 10/17/2012 12:43 AM, Kevin Anthony wrote:> Is it not true that list 
> >> comprehension is much faster the the for loops?
> 
> >>
> 
> >>> If it is not the correct way of doing this, i appoligize.
> 
> >>> Like i said, I'm learing list comprehension.
> 
> >> list comprehensions CAN be much faster, but not necessarily.  The most
> 
> >> complex a loop, the less likely it'll help much.
> 
> > One-lining the comprehension seems to make a difference of about 10%
> 
> > out here. Maybe Ive missed something? Seems too large�
> 
> >
> 
> > # My original suggestion
> 
> > def dot(p,q): return sum (x*y for x,y in zip(p,q))
> 
> > def transpose(m): return zip(*m)
> 
> > def mm(a,b): return mmt(a, transpose(b))
> 
> > def mmt(a,b): return [[dot(ra, rb) for rb in b] for ra in a]
> 
> >
> 
> > # One-liner (Thanks Hans for reminding me of sum)
> 
> >
> 
> > def mm1(a,b): return [[sum([x*y for x,y in zip(ra,rb)]) for rb in
> 
> > zip(*b)] for ra in a]
> 
> >
> 
>  t1=Timer("res=mm1(m,m)", setup="from __main__ import mm1, m")
> 
>  t1.timeit(1000)
> 
> > 12.276363849639893
> 
>  t0=Timer("res=mm(m,m)", setup="from __main__ import mm, m")
> 
>  t0.timeit(1000)
> 
> > 13.453603029251099
> 
> 
> 
> And I'd wager all the improvement is in the inner loop, the dot() function.
> 
> 
> 
> 
> 
> -- 
> 
> 
> 
> DaveA

Thanks for the tips of matrix operations over some fields or rings 
other than the real field and the complex field.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: list comprehension question

[88888 Dihedral]

rusi於 2012年10月17日星期三UTC+8下午10時50分11秒寫道：
> On Oct 17, 7:37 pm, Dave Angel  wrote:
> 
> 
> 
> > And I'd wager all the improvement is in the inner loop, the dot() function.
> 
> 
> 
> Sorry -- red herring!
> 
> 
> 
> Changing
> 
> 
> 
> def mm1(a,b): return [[sum(x*y for x,y in zip(ra,rb)) for rb in
> 
> zip(*b)] for ra in a]
> 
> 
> 
> to
> 
> 
> 
> def mm1(a,b): return [[sum([x*y for x,y in zip(ra,rb)]) for rb in
> 
> zip(*b)] for ra in a]
> 
> 
> 
> makes the speed diff vanish

I think a lot people don't work on computations over 
fields other real and complex.

That is why a lot people keep complaining about the speeds 
of python programs executed.

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

Re: Remove uncide notation

[88888 Dihedral]

Ashish Jain於 2012年10月18日星期四UTC+8下午5時27分04秒寫道：
> Hi,
> 
> 
> 
> I have a html string in an object, when I do repr() of that object, I get 
> value as:
> 
> 
> 
> {'Id' : 1, 'Body': u' Hello '}
> 
> 
> 
> I don't wish to have 'u' as the character in my string representation. As 
> this is not a valid json notation now.
> 
> 
> 
> Thanks for your help
> 
> 
> 
> -Ashish

I remembered about 15 years ago that the MS office and IE were
supporting different languages all over the world to collect money$$$!

Of course there were ISO standards. But in business Wintel did 
several very good jobs before year 2000 for those different encodings of 
languages.

Now the unicode is the default standard in software development 
for multi-lingual supports of web sites all over the world. 
 

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