Re: Obnoxious postings from Google Groups

[Bob Martin]

in 684220 20121102 093654 Jamie Paul Griffin  wrote:
>/ ru...@yahoo.com wrote on Thu  1.Nov'12 at 15:08:26 -0700 /
>
>> On 11/01/2012 03:55 AM, Jamie Paul Griffin wrote:
>> > Anybody serious about programming should be using a form of
>> > UNIX/Linux if you ask me. It's inconceivable that these systems
>> > should be avoided if you're serious about Software Engineering and
>> > Computer Science, etc. For UNIX there are loads of decent news
>> > reading software and mail user agents to learn and use. slrn is a
>> > good one and point it at gmane.org as someone else pointed out. I
>> > can't even imagine using a browser or Google Groups, etc. now.
>
>> Are you saying that this group is only for "serious" programmers?
>
>I don't see where my comments suggested that this group is only for serious 
>programmers. I simply believe that the UNIX platform, in whatever form, is 
>better placed and designed for all sorts of computing and engineering 
>projects. The history of UNIX speaks for itself. Many Universities that offer 
>respected and credible science based degree programmes, namely engineering and 
>computing programmes, strongly encourage students to become competent with 
>UNIX systems. Windows in my opinion is really for those who use the internet 
>on a casual basis or in a commercial environment where its staff are not 
>necessarily computer literate and therefore need a platform that they can use 
>which doesn't require them to learn more complex techniques and protocols. 
>But, having said that, I'm not against Windows at all. I use it frequently and 
>enjoy using it most of the time.
>
>> "serious" is also a matter of opinion.  I have some serious
>> programmer friends who maintain, in complete sincerity, that
>> serious programmers should not waste time on slow, script-kiddie
>> languages like Python, but should be developing their skills
>> with serious professional languages like Java, C#, etc.
>
>That is a narrow minded approach. different languages serve different purposes 
>and it's down to the developer to use which language she needs to achieve what 
>it is they've set out to do. Sometimes, basic shell scripts can be extremely 
>powerful for certain tasks; other needs will require something different. I 
>certainly wouldn't describe Python as a "script-kiddie" language. It's 
>extremely powerful and modern. So there ;-P lol

Real programmers (can) write in assembler.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: better way for ' '.join(args) + '\n'?

[Ramchandra Apte]

On Saturday, 27 October 2012 03:12:31 UTC+5:30, Tycho Andersen  wrote:
> On Fri, Oct 26, 2012 at 05:36:50PM -0400, Dave Angel wrote:
> 
> > On 10/26/2012 05:26 PM, Tycho Andersen wrote:
> 
> > > Assuming it's the length of the list that's the problem, not the
> 
> > > length of the strings in the list...
> 
> > >
> 
> > > args = ['foo', 'bar', 'baz']
> 
> > > args[-1] = args[-1] + '\n'
> 
> > > line = ' '.join(args)
> 
> > >
> 
> > > \t
> 
> > 
> 
> > Main problem with that is the trailing space before the newline.  If
> 
> > that's not a problem, then fine.
> 
> 
> 
> What trailing space before the newline? The other solutions have it,
> 
> the above does not. However, the above does mutate args, which isn't
> 
> all that great. Alas, if you want the performance of mutable
> 
> structures, you're probably going to have to mutate something. (In any
> 
> case, it's easy enough to change it back, though ugly.)
> 
> 
> 
> > Not sure why we try so hard to optimize something that's going to take
> 
> > negligible time.
> 
> 
> 
> The same reason some people enjoy sporting events: it's fun :-)
Me too
> 
> 
> 
> \t
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: enabling universal newline

[Peter Otten]

Steven D'Aprano wrote:

> On Fri, 02 Nov 2012 23:22:53 +0100, Peter Kleiweg wrote:
> 
>> In Python 3.1 and 3.2
>> 
>> At start-up, the value of sys.stdin.newlines is None, which means,
>> universal newline should be enabled. But it isn't.
> 
> What makes you think it is not enabled?

$ python3 -c 'open("tmp.txt", "wb").write(b"a\nb\r\nc\rd")'

This is the output with universal newlines:

$ python3 -c 'print(open("tmp.txt").readlines())'
['a\n', 'b\n', 'c\n', 'd']

But this is what you get from stdin:

$ cat tmp.txt | python3 -c 'import sys; print(sys.stdin.readlines())'
['a\n', 'b\r\n', 'c\rd']

With Peter Kleiweg's fix:

$ cat tmp.txt | python3 -c 'import sys, io; 
print(io.TextIOWrapper(sys.stdin.detach(), newline=None).readlines())'
['a\n', 'b\n', 'c\n', 'd']

I think it's reasonable to make the latter the default.

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

RE: How to generate account number?

[Andriy Kornatskyy]

Jose, absolutely, let me know should you have any issues.

Andriy


> Date: Fri, 2 Nov 2012 15:29:13 -0600
> Subject: Re: How to generate account number?
> From: josen.figue...@unixmexico.org
> To: andriy.kornats...@live.com
> CC: python-list@python.org
>
> Hello Andriy
>
> Thanks for your work!
>
> I will try it!
> Jose
>
>
> On Fri, Nov 2, 2012 at 3:13 PM, Andriy Kornatskyy
> mailto:andriy.kornats...@live.com>> wrote:
>
> Requirements for `account number` generator:
>
> 1. Issue pseudo random consistent number (must be unique for dozen
> millions of records)
> 2. Easy check validity (without a need to make a database call)
>
> Interested? Read more here:
>
> http://mindref.blogspot.com/2012/11/generate-account-number.html
>
> Comments or suggestions are welcome.
>
> Thanks.
>
> Andriy Kornatskyy
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: enabling universal newline

[Peter Kleiweg]

Steven D'Aprano schreef op de 2e dag van de slachtmaand van het jaar 2012:

> On Fri, 02 Nov 2012 23:22:53 +0100, Peter Kleiweg wrote:
> 
> > In Python 3.1 and 3.2
> > 
> > At start-up, the value of sys.stdin.newlines is None, which means,
> > universal newline should be enabled. But it isn't.
> 
> What makes you think it is not enabled?

Script 1:

#!/usr/bin/env python3.1
import sys
print(sys.stdin.readlines())

Output:

~ test.py < text
['a\rbc\rdef\r']


Script 2:

#!/usr/bin/env python3.1
import io, sys
sys.stdin = io.TextIOWrapper(sys.stdin.detach(), newline=None)
print(sys.stdin.readlines())

Output:

~ test.py < text
['a\n', 'bc\n', 'def\n']


-- 
Peter Kleiweg
http://pkleiweg.home.xs4all.nl/
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: How to generate account number?

[Andriy Kornatskyy]

>>> from hashlib import sha1
>>> sha1('GangGreene-20120203-1012').hexdigest()
'ef764a2fe44532008dc9a99c391c70cd85ec9d82'

It is too long and not verifiable.

>>> from uuid import uuid4

>>> uuid4()

UUID('2c14484b-5a0c-4f4b-b7bc-8187548b4888')

Pretty much the same what you suggest but simpler and shorter. Not quite 
elegant for humans.

Here are examples per this post:
http://mindref.blogspot.com/2012/11/generate-account-number.html

>>> account_number(1)
'Z05738521581'
>>> account_number(2)
'Z17888279480'
>>> account_number(3)
'Z07395350007'

Short, human readable and satisfy original requirements.

Andriy



> From: ganggre...@example.com
> Subject: Re: How to generate account number?
> Date: Fri, 2 Nov 2012 18:02:09 -0400
> To: python-list@python.org
>
> On Sat, 03 Nov 2012 00:13:19 +0300, Andriy Kornatskyy wrote:
>
>> Requirements for `account number` generator:
>>
>> 1. Issue pseudo random consistent number (must be unique for dozen
>> millions of records)
>> 2. Easy check validity (without a need to make a database call)
>>
>> Interested? Read more here:
>>
>> http://mindref.blogspot.com/2012/11/generate-account-number.html
>>
>> Comments or suggestions are welcome.
>>
>> Thanks.
>>
>> Andriy Kornatskyy
>
> generate sha1sum on the ((key database record(s))+date+timeofday)
> Should be unique for billions/trillions of records.
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: How to generate account number?

[Andriy Kornatskyy]

Steven, see below, please.


> From: steve+comp.lang.pyt...@pearwood.info
> Subject: Re: How to generate account number?
> Date: Fri, 2 Nov 2012 22:39:31 +
> To: python-list@python.org
>
> On Sat, 03 Nov 2012 00:13:19 +0300, Andriy Kornatskyy wrote:
>
>> Requirements for `account number` generator:
>>
>> 1. Issue pseudo random consistent number (must be unique for dozen
>> millions of records)
>
> How much randomness do you need? From the perspective of any one user, a
> simple incrementing counter returns arbitrary values, which may be "close
> enough" to random.
>
> last_num = 103872 # Pick an arbitrary starting value.
> def get_account_number():
> """Return the next account number."""
> global last_num
> last_num += 1
> return last_num
>
> Stick that value in a database instead of a global, and you're done.
>
> What are the consequences of people guessing account numbers? If the
> consequences are serious, then you need to make account numbers
> cryptographically strong. If the account number alone is not important,
> then you don't.

Yes. There are consequences to not use sequential numbers, yet humans deal with 
it (enter as input somewhere, etc). The approach suggested here:

http://mindref.blogspot.com/2012/11/generate-account-number.html

is using Feistel cipher to generate pseudo random thus makes guessing account 
numbers hard (impossible?).

>> 2. Easy check validity (without a need to make a database call)
>
> Add a check digit to the number you generate. There are all sorts of ways
> to do that. Here are two examples:
>
> http://code.activestate.com/recipes/577692
> http://code.activestate.com/recipes/577691

These tell me how to verify some code, but doesn't how to generate it. The 
approach suggested here:

http://mindref.blogspot.com/2012/11/generate-account-number.html

gives you ability to customize `sample_f` function to make it unique to your 
business case.

>> Interested? Read more here:
>
> If you ask a question here, please keep the discussion here, don't split
> it to your personal blog.

The question was rhetorical with my answer in the blog and discussion here to 
reach something.

> Tell us your requirements in more detail, and we will try to help you.

I have presented solution to `account number` challenge. So it was share with 
community and seek for thoughts if any.



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

Re: How to improve the usability of nested packages

[Michael Schwarz]

Hi Terry

On 2012-W44-5, at 18:56, Terry Reedy wrote:

>> or would you maybe structure the library entirely different?
> 
> Based on my limited experience with subpackages* plus reports on this list 
> about problems, such as yours, I have concluded that subpackages are an 
> attractive nuisance that are generally more trouble than they are worth. I 
> suggest you consider sticking with your original flat (no subpackage) design. 
> (But maybe someone knows better than me how to make subpackages work ;-).

One thing that I would lose is the way I can choose very short names for the 
packages and modules that are imported into the local namespace (like sip or 
rtp) and also add new stuff without fearing a namespace conflict in one of the 
applications using the library.

I really hope there is a better way :-(.

Michael

smime.p7s
Description: S/MIME cryptographic signature
-- 
http://mail.python.org/mailman/listinfo/python-list

install pyOpenSSL in python2.7

[????????]

i have install  pyOpenSSL-0.11  in python2.7  this way:
download  pyOpenSSL-0.11.tar.gz
 #tar -zvxf pyOpenSSL-0.11.tar.gz
 #cd pyOpenSSL-0.11
 #python setup.py install

>>> import  OpenSSL
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/OpenSSL/__init__.py", line 45, 
in 
from OpenSSL import rand, SSL
ImportError: /usr/local/lib/python2.7/dist-packages/OpenSSL/SSL.so: undefined 
symbol: SSLv2_method


how can i fix the  problem?
ImportError: /usr/local/lib/python2.7/dist-packages/OpenSSL/SSL.so: undefined 
symbol: SSLv2_method-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to improve the usability of nested packages

[Michael Schwarz]

Hi Stefan

On 2012-W44-5, at 19:23, Stefan H. Holek wrote:

> That said, there are ways to avoid import cycles. One is to very carefully 
> craft your modules so they do not have to import from each other. Another is 
> to not have imports at the module level, but move them into the functions 
> where they are required.

I've also thought about that. I do not like the fact that I then need to 
educate the other developers about minute details of the import machinery just 
so they can add code to the library. I'm currently the only developer doing 
actual work in Python and would like to make the transition as painless as 
possible.

> Third, large libraries like the Zope Toolkit usually have mechanisms to defer 
> imports to some point after initial loading. You may want explore this 
> direction as well. [2]

Hmm, I like the idea but sadly it doesn't look very IDE-friendly.

Thanks for your tips!
Michael

[1]: http://docs.zope.org/zopetoolkit/codingstyle/python-style.html

smime.p7s
Description: S/MIME cryptographic signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Google spreadsheets - getting started

[Mark Carter]

I want to mess around with my online Google spreadsheets from my Linux box 
programmatically. I am TOTALLY confused.

I've got gdata installed, and it appears that the best way to access the 
spreadsheets is to authenticate with Oauth2.

Here's the main thing: how do I get an Oauth2 key to use with Google 
spreadsheets?

I obtain a "p12" key, but I don't know if that's for something completely 
different.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Google spreadsheets - getting started

[Mark Carter]

OK, maybe the p12 file is useful after all (?) I've got the following code:

import gdata

tokenfile = "my-privatekey.p12"
f = open(tokenfile, 'r')
blob = f.read()
f.close()
token = gdata.gauth.token_from_blob(blob)

When I run that I get:
Traceback (most recent call last):
  File "/home/mcarter/wapp.py", line 8, in 
token = gdata.gauth.token_from_blob(blob)
AttributeError: 'module' object has no attribute 'gauth'

I guess I'm using a newer version of gdata (2.0.14). 

None of this makes any sense.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Google spreadsheets - getting started

[Mark Carter]

OK, the story so far:


import gdata
import gdata.auth
import gdata.gauth
import gdata.docs.service
import OpenSSL.crypto

tokenfile = "privatekey.p12"
#f = open(tokenfile, 'r')
#blob = f.read()
#f.close()
#if blob:
p12 = OpenSSL.crypto.load_pkcs12(file(tokenfile, 'rb').read(), 'notasecret')
print p12.get_certificate() 

#token = gdata.gauth.token_from_blob(p12)
#print "token: ", token

gd_client = gdata.docs.service.DocsService()
#gd_client.SetOAuthToken(token)
gd_client.SetOAuthToken(p12)

feed = gd_client.GetDocumentListFeed() # line 22
for entry in feed.entry:
  print entry.title.text.encode('UTF-8')

print "Finished"



It baulks as follows:
/usr/bin/python -u  "/home/mcarter/wapp.py"

Traceback (most recent call last):
  File "/home/mcarter/wapp.py", line 22, in 
feed = gd_client.GetDocumentListFeed()
  File "/usr/lib/pymodules/python2.7/gdata/docs/service.py", line 259, in 
GetDocumentListFeed
return self.QueryDocumentListFeed(uri)
  File "/usr/lib/pymodules/python2.7/gdata/docs/service.py", line 238, in 
QueryDocumentListFeed
return self.Get(uri, converter=gdata.docs.DocumentListFeedFromString)
  File "/usr/lib/pymodules/python2.7/gdata/service.py", line 1068, in Get
headers=extra_headers)
  File "/usr/lib/pymodules/python2.7/atom/__init__.py", line 92, in 
optional_warn_function
return f(*args, **kwargs)
  File "/usr/lib/pymodules/python2.7/atom/service.py", line 184, in request
return auth_token.perform_request(self.http_client, operation, url, 
AttributeError: 'PKCS12' object has no attribute 'perform_request'


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

Re: How to generate account number?

[Roy Smith]

In article ,
 Andriy Kornatskyy  wrote:

> 'Z05738521581'
> 'Z17888279480'
> 'Z07395350007'
> 
> Short, human readable and satisfy original requirements.
> 
> Andriy

If you really want human readable, it's better to chunk the data up into 
3 or 4 digit groups.  So, instead of Z05738521581, maybe 
Z05-738-521-581.  Or perhaps even better, Z05-7385-21-581 (just a hunch, 
but I suspect varying the length of the groups makes it easier to read).

Even better might be base-32 encoding the value.  Strings of digits have 
an information density of about 3.2 bits/char. Base-32 is just about as 
readable, but gives you 5 bits/char, so you end up with a few less 
characters (which you still want to chunk into 3 or 4 character groups).
-- 
http://mail.python.org/mailman/listinfo/python-list

What is Islam?

[BV BV]

What is Islam?

In this episode Shaikh Yusuf Estes Explains the meaning of Islam in
detail.


http://youtube.googleapis.com/v/Gl-wuhzOkpo?rel=0



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

Re: Obnoxious postings from Google Groups

[Dave Angel]

On 11/03/2012 03:44 AM, Bob Martin wrote:
> 
>>
> Real programmers (can) write in assembler.

Real programmers can (and have) write in hex/octal or binary.  For my
first project at a permanent job, I had to write code for a machine with
no assembler.  Near the end of the project, I wrote a text editor and
(cross) assembler for it, because maintaining the source with pen/ink
was getting tedious.

For the DOS world, real programmers have written a "complete"  *.com 
program using only echo.

-- 

DaveA

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

Re: How to generate account number?

[Michael Torrie]

On 11/02/2012 03:13 PM, Andriy Kornatskyy wrote:
> 
> Requirements for `account number` generator:
> 
> 1. Issue pseudo random consistent number (must be unique for dozen millions 
> of records)
> 2. Easy check validity (without a need to make a database call)
> 
> Interested? Read more here:
> 
> http://mindref.blogspot.com/2012/11/generate-account-number.html
> 
> Comments or suggestions are welcome.

Thank you for sharing.  Your post came along at just the right time.  I
was just pondering on how to create a number that is unique each time
(or most of the time), and unlikely to be guessed ahead of time.  Your
technique should work very well for me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to generate account number?

[Tim Chase]

On 11/03/12 08:22, Roy Smith wrote:
> Even better might be base-32 encoding the value.  Strings of
> digits have an information density of about 3.2 bits/char.
> Base-32 is just about as readable, but gives you 5 bits/char, so
> you end up with a few less characters (which you still want to
> chunk into 3 or 4 character groups).

For things that will be read off a screen/paper, I recommend
omitting several letters that are easy to mistake visually:  i/I/l/1
and O/0 in particular.  The VIN (vehicle identification number) on
all US cars avoids these characters[*], making it easier to read
them back without concern for "is that a zero or an oh; and is that
an ell, a one, a lowercase eye, or a capital eye?"  As an encoding
advantage,

>>> print len(''.join(c for c in (string.ascii_uppercase +
string.digits) if c not in "O0iIl1"))
32

the number 32 is pretty handy when dealing with binary :-)

-tkc


[*]
The VIN avoids "Q" too and does use the digits 0/1, but the idea
holds.  Make it easy to ready back.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Obnoxious postings from Google Groups

[Chris Angelico]

On Sun, Nov 4, 2012 at 1:24 AM, Dave Angel  wrote:
> For the DOS world, real programmers have written a "complete"  *.com
> program using only echo.

Only as an exercise. It was satisfying to prove to myself that I could
do it, but pretty useless. Normally I used DEBUG.EXE to build my code
- it has a mini-assembler in it. Incidentally, I used debug as a full
assembler, with a bit of a REXX harness around it - used that to write
OS/2 code in pure assembly, without the bother of, yaknow, getting an
actual assembler. Suddenly things got WAY easier once I got hold of
nasm...

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

RE: How to generate account number?

[Andriy Kornatskyy]

Roy,

Per your advise:

>>> from base64 import b32encode
>>> human_format = lambda n: 'Z%s-%s' % (b32encode(chr((n >> 24) & 255) + 
>>> chr((n >> 16) & 255))[:4], b32encode(chr((n >> 8) & 255) + chr(n & 
>>> 255))[:4])
>>> human_format(5738521581)
'ZKYFA-4PWQ'
>>> human_format(17888279480)
'ZFI4Q-PO4A'
>>> human_format(7395350007)
'ZXDGA-CX3Q'

Side by side:

Z05738521581 = ZKYFA-4PWQ
Z17888279480 = ZFI4Q-PO4A
Z07395350007 = ZXDGA-CX3Q

Thanks.

Andriy



> From: r...@panix.com
> Subject: Re: How to generate account number?
> Date: Sat, 3 Nov 2012 09:22:55 -0400
> To: python-list@python.org
>
> In article ,
> Andriy Kornatskyy  wrote:
>
> > 'Z05738521581'
> > 'Z17888279480'
> > 'Z07395350007'
> >
> > Short, human readable and satisfy original requirements.
> >
> > Andriy
>
> If you really want human readable, it's better to chunk the data up into
> 3 or 4 digit groups. So, instead of Z05738521581, maybe
> Z05-738-521-581. Or perhaps even better, Z05-7385-21-581 (just a hunch,
> but I suspect varying the length of the groups makes it easier to read).
>
> Even better might be base-32 encoding the value. Strings of digits have
> an information density of about 3.2 bits/char. Base-32 is just about as
> readable, but gives you 5 bits/char, so you end up with a few less
> characters (which you still want to chunk into 3 or 4 character groups).
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Obnoxious postings from Google Groups

[Steven D'Aprano]

On Sat, 03 Nov 2012 10:24:15 -0400, Dave Angel wrote:

> For the DOS world, real programmers have written a "complete"  *.com
> program using only echo.

Echo? Wimps. Real programmers write their code directly on the surface of 
the hard drive using only a magnetised needle.


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

RE: How to generate account number?

[Andriy Kornatskyy]

Tim,

Good point. b32decode seems to be capable to understand such common mistakes 
(see map01 argument to b32decode), I haven't tried:

http://docs.python.org/2/library/base64.html

Thanks.

Andriy


> Date: Sat, 3 Nov 2012 10:34:26 -0500
> From: python.l...@tim.thechases.com
> To: r...@panix.com
> Subject: Re: How to generate account number?
> CC: python-list@python.org
>
> On 11/03/12 08:22, Roy Smith wrote:
> > Even better might be base-32 encoding the value. Strings of
> > digits have an information density of about 3.2 bits/char.
> > Base-32 is just about as readable, but gives you 5 bits/char, so
> > you end up with a few less characters (which you still want to
> > chunk into 3 or 4 character groups).
>
> For things that will be read off a screen/paper, I recommend
> omitting several letters that are easy to mistake visually: i/I/l/1
> and O/0 in particular. The VIN (vehicle identification number) on
> all US cars avoids these characters[*], making it easier to read
> them back without concern for "is that a zero or an oh; and is that
> an ell, a one, a lowercase eye, or a capital eye?" As an encoding
> advantage,
>
> >>> print len(''.join(c for c in (string.ascii_uppercase +
> string.digits) if c not in "O0iIl1"))
> 32
>
> the number 32 is pretty handy when dealing with binary :-)
>
> -tkc
>
>
> [*]
> The VIN avoids "Q" too and does use the digits 0/1, but the idea
> holds. Make it easy to ready back.
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Haskell -> Python

[Duncan Booth]

Ian Kelly  wrote:

> On Fri, Nov 2, 2012 at 1:19 PM,   wrote:
>> Is there anything anyone could recommend to make it more "Pythonic"
>> or more functional.  It looks clumsy next to the Haskell. 
> 
> def options(heaps):
> for i, heap in enumerate(heaps):
> head = heaps[:i]
> tail = heaps[i+1:]
> yield from (head + [x] + tail for x in range(heap))
> 
> "yield from" is Python 3.3 syntax.  If you're not using Python 3.3,
> then that line could be replaced by:
> 
> for x in range(heap):
> yield head + [x] + tail
> 
> Cheers,
> Ian

An alternative that is closer to foster63's original but still more 
"Pythonic" for some definitions of those words.

def options(heaps):
if not heaps: return []
head, *tail = heaps
for h in range(head):
yield [h]+tail
for t in options(tail):
yield [head]+t

For a more 'functional' version there is also the Python 3.3 variant:

def options(heaps):
if not heaps: return []
head, *tail = heaps
yield from ([h]+tail for h in range(head))
yield from ([head]+t for t in options(tail))

-- 
Duncan Booth http://kupuguy.blogspot.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is implemented with id ?

[Aahz]

[got some free time, catching up to threads two months old]

In article <50475822$0$6867$e4fe5...@news2.news.xs4all.nl>,
Hans Mulder   wrote:
>On 5/09/12 15:19:47, Franck Ditter wrote:
>>
>> - I should have said that I work with Python 3. Does that matter ?
>> - May I reformulate the queston : "a is b" and "id(a) == id(b)"
>>   both mean : "a et b share the same physical address". Is that True ?
>
>Yes.
>
>Keep in mind, though, that in some implementation (e.g.  Jython), the
>physical address may change during the life time of an object.
>
>It's usually phrased as "a and b are the same object".  If the object
>is mutable, then changing a will also change b.  If a and b aren't
>mutable, then it doesn't really matter whether they share a physical
>address.

That last sentence is not quite true.  intern() is used to ensure that
strings share a physical address to save memory.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"Normal is what cuts off your sixth finger and your tail..."  --Siobhan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is implemented with id ?

[Hans Mulder]

On 3/11/12 20:41:28, Aahz wrote:
> [got some free time, catching up to threads two months old]
> 
> In article <50475822$0$6867$e4fe5...@news2.news.xs4all.nl>,
> Hans Mulder   wrote:
>> On 5/09/12 15:19:47, Franck Ditter wrote:
>>>
>>> - I should have said that I work with Python 3. Does that matter ?
>>> - May I reformulate the queston : "a is b" and "id(a) == id(b)"
>>>   both mean : "a et b share the same physical address". Is that True ?
>>
>> Yes.
>>
>> Keep in mind, though, that in some implementation (e.g.  Jython), the
>> physical address may change during the life time of an object.
>>
>> It's usually phrased as "a and b are the same object".  If the object
>> is mutable, then changing a will also change b.  If a and b aren't
>> mutable, then it doesn't really matter whether they share a physical
>> address.
> 
> That last sentence is not quite true.  intern() is used to ensure that
> strings share a physical address to save memory.

That's a matter of perspective: in my book, the primary advantage of
working with interned strings is that I can use 'is' rather than '=='
to test for equality if I know my strings are interned.  The space
savings are minor; the time savings may be significant.

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

Re: is implemented with id ?

[Steven D'Aprano]

On Sat, 03 Nov 2012 22:49:07 +0100, Hans Mulder wrote:

> On 3/11/12 20:41:28, Aahz wrote:
>> [got some free time, catching up to threads two months old]
>> 
>> In article <50475822$0$6867$e4fe5...@news2.news.xs4all.nl>, Hans Mulder
>>   wrote:
>>> On 5/09/12 15:19:47, Franck Ditter wrote:

 - I should have said that I work with Python 3. Does that matter ? -
 May I reformulate the queston : "a is b" and "id(a) == id(b)"
   both mean : "a et b share the same physical address". Is that True
   ?
>>>
>>> Yes.
>>>
>>> Keep in mind, though, that in some implementation (e.g.  Jython), the
>>> physical address may change during the life time of an object.
>>>
>>> It's usually phrased as "a and b are the same object".  If the object
>>> is mutable, then changing a will also change b.  If a and b aren't
>>> mutable, then it doesn't really matter whether they share a physical
>>> address.
>> 
>> That last sentence is not quite true.  intern() is used to ensure that
>> strings share a physical address to save memory.
> 
> That's a matter of perspective: in my book, the primary advantage of
> working with interned strings is that I can use 'is' rather than '==' to
> test for equality if I know my strings are interned.  The space savings
> are minor; the time savings may be significant.

Actually, for many applications, the space "savings" may actually be 
*costs*, since interning forces Python to hold onto strings even after 
they would normally be garbage collected. CPython interns strings that 
look like identifiers. It really wouldn't be a good idea for it to 
automatically intern every string.

You can make your own intern system with a simple dict:

interned_strings = {}

Then, for every string you care about, do:

s = interned_strings.set_default(s, s)

to ensure you are always working with a single string object for each 
unique value. In some applications that will save time at the expense of 
space.

And there is no need to write "is" instead of "==", because string 
equality already optimizes the "strings are identical" case. By using ==, 
you don't get into bad habits, you defend against the odd un-interned 
string sneaking in, and you still have high speed equality tests.


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

Fwd: Re: Negative array indicies and slice()

[Andrew Robinson]

Forwarded to python list:

 Original Message 
Subject:Re: Negative array indicies and slice()
Date:   Sat, 03 Nov 2012 15:32:04 -0700
From:   Andrew Robinson
Reply-To:   andr...@r3dsolutions.com
To: Ian Kelly <>



On 11/01/2012 05:32 PM, Ian Kelly wrote:

 On Thu, Nov 1, 2012 at 4:25 PM, Andrew Robinson

 The bottom line is:  __getitem__ must always *PASS* len( seq ) to slice()
 each *time* the slice() object is-used.  Since this is the case, it would
 have been better to have list, itself, have a default member which takes the
 raw slice indicies and does the conversion itself.  The size would not need
 to be duplicated or passed -- memory savings,&   speed savings...

 And then tuple would need to duplicate the same code.  As would deque.
   And str.  And numpy.array, and anything else that can be sliced,
 including custom sequence classes.

I don't think that's true.  A generic function can be shared among
different objects without being embedded in an external index data
structure to boot!

If *self* were passed to an index conversion function (as would
naturally happen anyway if it were a method), then the method could take
len( self ) without knowing what the object is;
Should the object be sliceable -- the len() will definitely return the
required piece of information.


 Numpy arrays are very different internally from lists.

Of course!  (Although, lists do allow nested lists.)


 I'm not understanding what this is meant to demonstrate.  Is "MyClass"
 a find-replace error of "ThirdParty"?  Why do you have __getitem__
 returning slice objects instead of items or subsequences?  What does
 this example have to do with numpy?

Here's a very cleaned up example file, cut and pastable:
#!/bin/env python
# File: sliceIt.py  --- a pre PEP357 hypothesis test skeleton

class Float16():
"""
Numpy creates a float type, with very limited precision -- float16
Rather than force you to install np for this test, I'm just making a
faux object.  normally we'd just "import np"
"""

def __init__(self,value): self.value = value
def AltPEP357Solution(self):
""" This is doing exactly what __index__ would be doing. """
return None if self.value is None else int( self.value )

class ThirdParty( list ):
"""
A simple class to implement a list wrapper, having all the
properties of
a normal list -- but explicitly showing portions of the interface.
"""
def __init__(self, aList): self.aList = aList

def __getitem__(self, aSlice):
print( "__getitems__", aSlice )
temp=[]
edges = aSlice.indices( len( self.aList ) ) # *unavoidable* call
for i in range( *edges ): temp.append( self.aList[ i ] )
return temp

def Inject_FloatSliceFilter( theClass ):
"""
This is a courtesy function to allow injecting (duck punching)
a float index filter into a user object.
"""
def Filter_FloatSlice( self, aSlice ):

# Single index retrieval filter
try: start=aSlice.AltPEP357Solution()
except AttributeError: pass
else: return self.aList[ start ]

# slice retrieval filter
try: start=aSlice.start.AltPEP357Solution()
except AttributeError: start=aSlice.start
try: stop=aSlice.stop.AltPEP357Solution()
except AttributeError: stop=aSlice.stop
try: step=aSlice.step.AltPEP357Solution()
except AttributeError: step=aSlice.step
print( "Filter To",start,stop,step )
return self.super_FloatSlice__getitem__( slice(start,stop,step) )

theClass.super_FloatSlice__getitem__ = theClass.__getitem__
theClass.__getitem__ = Filter_FloatSlice

# EOF: sliceIt.py


Example run:


 from sliceIt import *
 test = ThirdParty( [1,2,3,4,5,6,7,8,9] )
 test[0:6:3]

('__getitems__', slice(0, 6, 3))
[1, 4]

 f16=Float16(8.3)
 test[0:f16:2]

('__getitems__', slice(0,, 2))
Traceback (most recent call last):
  File "", line 1, in
  File "sliceIt.py", line 26, in __getitem__
edges = aSlice.indices( len( self.aList ) )  # This is an
*unavoidable* call
TypeError: object cannot be interpreted as an index

 Inject_FloatSliceFilter( ThirdParty )
 test[0:f16:2]

('Filter To', 0, 8, 2)
('__getitems__', slice(0, 8, 2))
[1, 3, 5, 7]

 test[f16]

9


 We could also require the user to explicitly declare when they're
 performing arithmetic on variables that might not be floats. Then we
 can turn off run-time type checking unless the user explicitly
 requests it, all in the name of micro-optimization and explicitness.

:) None of those would help micro-optimization that I can see.

 Seriously, whether x is usable as a sequence index is a property of x,
 not a property of the sequence.

Yes, but the *LENGTH* of the sequence is a function of the *sequence*.

 Users shouldn't need to pick and choose *which* particular sequence
 index types their custom sequences are willing to accept. 

Re: is implemented with id ?

[Roy Smith]

In article <50959154$0$6880$e4fe5...@news2.news.xs4all.nl>,
 Hans Mulder  wrote:

> That's a matter of perspective: in my book, the primary advantage of
> working with interned strings is that I can use 'is' rather than '=='
> to test for equality if I know my strings are interned.  The space
> savings are minor; the time savings may be significant.

Depending on your problem domain, the space savings may be considerable.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is implemented with id ?

[Chris Angelico]

On Sun, Nov 4, 2012 at 9:18 AM, Steven D'Aprano
 wrote:
> On Sat, 03 Nov 2012 22:49:07 +0100, Hans Mulder wrote:
> Actually, for many applications, the space "savings" may actually be
> *costs*, since interning forces Python to hold onto strings even after
> they would normally be garbage collected. CPython interns strings that
> look like identifiers. It really wouldn't be a good idea for it to
> automatically intern every string.

I don't know about that.

/* This dictionary holds all interned unicode strings.  Note that references
   to strings in this dictionary are *not* counted in the string's ob_refcnt.
   When the interned string reaches a refcnt of 0 the string deallocation
   function will delete the reference from this dictionary.

   Another way to look at this is that to say that the actual reference
   count of a string is:  s->ob_refcnt + (s->state ? 2 : 0)
*/
static PyObject *interned;

Empirical testing (on a Linux 3.3a0 that I had lying around) showed
the process's memory usage drop, but I closed the terminal before
copying and pasting (oops). Attempting to recreate in IDLE on 3.2 on
Windows.

>>> a="$"*1024*1024*256# Make $$$$$$ fast!
>>> import sys
>>> sys.getsizeof(a)# Clearly this is a narrow build
536870942
>>> a="$"*1024*1024*256
--> MemoryError. Blah. This is what I get for only having a gig and a
half in this laptop. And I was working with 1024*1024*1024 on the
other box. Start over...

>>> import sys
>>> a="$"*1024*1024*128
>>> b="$"*1024*1024*128
>>> a is b
False
>>> a=sys.intern(a)
>>> b=sys.intern(b)
>>> c="$"*1024*1024*128
>>> c=sys.intern(c)

Memory usage (according to Task Mangler) goes up to ~512MB when I
create a new string (like c), then back down to ~256MB when I intern
it. So far so good.

>>> del a,b,c

Memory usage has dropped to 12MB. Unnecessarily-interned strings don't
cost anything. (The source does refer to immortal interned strings,
but AFAIK you can't create them in user-level code. At least, I didn't
find it in help(sys.intern) which is the obvious place to look.)

> You can make your own intern system with a simple dict:
>
> interned_strings = {}
>
> Then, for every string you care about, do:
>
> s = interned_strings.set_default(s, s)
>
> to ensure you are always working with a single string object for each
> unique value. In some applications that will save time at the expense of
> space.

Doing it manually like this _will_ leak like that, though, unless you
periodically check sys.getrefcount and dispose of unreferenced
entries.

> And there is no need to write "is" instead of "==", because string
> equality already optimizes the "strings are identical" case. By using ==,
> you don't get into bad habits, you defend against the odd un-interned
> string sneaking in, and you still have high speed equality tests.

This one I haven't checked the source for, but ISTR discussions on
this list about comparison of two unequal interned strings not being
optimized, so they'll end up being compared char-for-char. Using 'is'
guarantees that the check stops with identity. This may or may not be
significant, and as you say, defending against an uninterned string
slipping through is potentially critical.

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

Re: is implemented with id ?

[Oscar Benjamin]

On 3 November 2012 22:50, Chris Angelico  wrote:
> This one I haven't checked the source for, but ISTR discussions on
> this list about comparison of two unequal interned strings not being
> optimized, so they'll end up being compared char-for-char. Using 'is'
> guarantees that the check stops with identity. This may or may not be
> significant, and as you say, defending against an uninterned string
> slipping through is potentially critical.

The source is here (and it shows what you suggest):
http://hg.python.org/cpython/file/6c639a1ff53d/Objects/unicodeobject.c#l6128

Comparing strings char for char is really not that big a deal though.
This has been discussed before: you don't need to compare very many
characters to conclude that strings are unequal (if I remember
correctly you were part of that discussion).

I can imagine cases where I might consider using intern on lots of
strings to speed up comparisons but I would have to be involved in
some seriously heavy and obscure string processing problem before I
considered using 'is' to compare those interned strings. That is
confusing to anyone who reads the code, prone to bugs and unlikely to
achieve the desired outcome of speeding things up (noticeably).


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

Re: is implemented with id ?

[Chris Angelico]

On Sun, Nov 4, 2012 at 12:14 PM, Oscar Benjamin
 wrote:
> On 3 November 2012 22:50, Chris Angelico  wrote:
>> This one I haven't checked the source for, but ISTR discussions on
>> this list about comparison of two unequal interned strings not being
>> optimized, so they'll end up being compared char-for-char. Using 'is'
>> guarantees that the check stops with identity. This may or may not be
>> significant, and as you say, defending against an uninterned string
>> slipping through is potentially critical.
>
> The source is here (and it shows what you suggest):
> http://hg.python.org/cpython/file/6c639a1ff53d/Objects/unicodeobject.c#l6128
>
> Comparing strings char for char is really not that big a deal though.
> This has been discussed before: you don't need to compare very many
> characters to conclude that strings are unequal (if I remember
> correctly you were part of that discussion).

Yes, and a quite wide-ranging discussion it was too! What color did we
end up whitewashing that bikeshed? *whistles innocently*

> I can imagine cases where I might consider using intern on lots of
> strings to speed up comparisons but I would have to be involved in
> some seriously heavy and obscure string processing problem before I
> considered using 'is' to compare those interned strings. That is
> confusing to anyone who reads the code, prone to bugs and unlikely to
> achieve the desired outcome of speeding things up (noticeably).

Good point. It's still true that 'is' will be faster, it's just not worth it.

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

PYTHON - Using Mosaic Qt Developer Suite with Qt Designer

[kapetanovic . zerina]

Hi,

I'm using Qt Designer to create a GUI that reads data from a file and plots in 
on a graph. I downloaded the Qt Developer and followed the directions in the 
readme.txt to add the plugins. My issue is that when I open Qt Designer the 
graphing widgets are not there to use. 

I was hoping to get some tips or advice on why this is not working.


Thanks in Advance,

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

Re: is implemented with id ?

[Steven D'Aprano]

On Sun, 04 Nov 2012 01:14:29 +, Oscar Benjamin wrote:

> On 3 November 2012 22:50, Chris Angelico  wrote:
>> This one I haven't checked the source for, but ISTR discussions on this
>> list about comparison of two unequal interned strings not being
>> optimized, so they'll end up being compared char-for-char. Using 'is'
>> guarantees that the check stops with identity. This may or may not be
>> significant, and as you say, defending against an uninterned string
>> slipping through is potentially critical.
> 
> The source is here (and it shows what you suggest):
> http://hg.python.org/cpython/file/6c639a1ff53d/Objects/
unicodeobject.c#l6128

I don't think it does, although I could be wrong, I find reading C to be 
quite difficult.

The unicode_compare function compares character by character, true, but 
it doesn't get called directly. The public interface is 
PyUnicode_Compare, which includes this test before calling 
unicode_compare:

/* Shortcut for empty or interned objects */
if (v == u) {
Py_DECREF(u);
Py_DECREF(v);
return 0;
}
result = unicode_compare(u, v);

where v and u are pointers to the unicode object.

So it appears that the test for strings being equal length have been 
dropped, but the identity test is still present.

> Comparing strings char for char is really not that big a deal though.

Depends on how big the string and where the first difference is.

> This has been discussed before: you don't need to compare very many
> characters to conclude that strings are unequal (if I remember correctly
> you were part of that discussion).

On average. Worst case, you have to look at every character.



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

Re: is implemented with id ?

[Chris Angelico]

On Sun, Nov 4, 2012 at 2:10 PM, Steven D'Aprano
 wrote:
> /* Shortcut for empty or interned objects */
> if (v == u) {
> Py_DECREF(u);
> Py_DECREF(v);
> return 0;
> }
> result = unicode_compare(u, v);
>
> where v and u are pointers to the unicode object.

There's a shortcut if they're the same. There's no shortcut if they're
both interned and have different pointers, which is a guarantee that
they're distinct strings. They'll still be compared char-for-char
until there's a difference.

But it probably isn't enough of a performance penalty to be concerned
with. It's enough to technically prove the point that 'is' is faster
than '==' and is still safe if both strings are interned; it's not
enough to make 'is' better than '==', except in very specific
situations.

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

Re: PYTHON - Using Mosaic Qt Developer Suite with Qt Designer

[Vincent Vande Vyvre]

Le 04/11/12 03:27, kapetanovic.zer...@gmail.com a écrit :
> Hi,
>
> I'm using Qt Designer to create a GUI that reads data from a file and plots 
> in on a graph. I downloaded the Qt Developer and followed the directions in 
> the readme.txt to add the plugins. My issue is that when I open Qt Designer 
> the graphing widgets are not there to use. 
>
> I was hoping to get some tips or advice on why this is not working.
>
>
> Thanks in Advance,
>
> Zerina
What plugin?, his name, eventually the link where you've downloaded it.

And what graphing widget?  QGraphicsView?

-- 
Vincent V.V.
Oqapy  . Qarte
 . PaQager 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is implemented with id ?

[Aahz]

In article ,
Chris Angelico   wrote:
>On Sun, Nov 4, 2012 at 2:10 PM, Steven D'Aprano
> wrote:
>>
>> /* Shortcut for empty or interned objects */
>> if (v == u) {
>> Py_DECREF(u);
>> Py_DECREF(v);
>> return 0;
>> }
>> result = unicode_compare(u, v);
>>
>> where v and u are pointers to the unicode object.
>
>There's a shortcut if they're the same. There's no shortcut if they're
>both interned and have different pointers, which is a guarantee that
>they're distinct strings. They'll still be compared char-for-char
>until there's a difference.

Without looking at the code, I'm pretty sure there's a hash check first.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"Normal is what cuts off your sixth finger and your tail..."  --Siobhan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is implemented with id ?

[Aahz]

In article <50959827$0$29967$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano   wrote:
>
>Actually, for many applications, the space "savings" may actually be 
>*costs*, since interning forces Python to hold onto strings even after 
>they would normally be garbage collected. 

That's old news, fixed in 2.5 or 2.6 IIRC -- interned strings now get
collected by refcounting like everything else.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"Normal is what cuts off your sixth finger and your tail..."  --Siobhan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is implemented with id ?

[Aahz]

In article <50959154$0$6880$e4fe5...@news2.news.xs4all.nl>,
Hans Mulder   wrote:
>On 3/11/12 20:41:28, Aahz wrote:
>> In article <50475822$0$6867$e4fe5...@news2.news.xs4all.nl>,
>> Hans Mulder   wrote:
>>> On 5/09/12 15:19:47, Franck Ditter wrote:

 - I should have said that I work with Python 3. Does that matter ?
 - May I reformulate the queston : "a is b" and "id(a) == id(b)"
   both mean : "a et b share the same physical address". Is that True ?
>>>
>>> Yes.
>>>
>>> Keep in mind, though, that in some implementation (e.g.  Jython), the
>>> physical address may change during the life time of an object.
>>>
>>> It's usually phrased as "a and b are the same object".  If the object
>>> is mutable, then changing a will also change b.  If a and b aren't
>>> mutable, then it doesn't really matter whether they share a physical
>>> address.
>> 
>> That last sentence is not quite true.  intern() is used to ensure that
>> strings share a physical address to save memory.
>
>That's a matter of perspective: in my book, the primary advantage of
>working with interned strings is that I can use 'is' rather than '=='
>to test for equality if I know my strings are interned.  The space
>savings are minor; the time savings may be significant.

As others have pointed out, using ``is`` with strings is a Bad Habit
likely leading to nasty, hard-to-find bugs.

intern() costs time, but saves considerable space in any application
with lots of duplicate computed strings (hundreds of megabytes in some
cases).
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"Normal is what cuts off your sixth finger and your tail..."  --Siobhan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Haskell -> Python

[Aahz]

In article ,
  wrote:
>
>def options( heaps ):
>
>if heaps == []: return []
>
>head, tail = heaps[:1], heaps[1:]
>
># Calculate all possible moves which is the sum of 
># prepending all possible head "moves" to the tail 
># and appending all possible tail "moves" to the head
>
>return [ [h] + tail for h in range( head[0] ) ] \
> + [ head + t   for t in options( tail )  ]
>
>Is there anything anyone could recommend to make it more "Pythonic" or
>more functional.  It looks clumsy next to the Haskell.

If you want more Pythonic, follow PEP8 in your formatting.  ;-)
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"Normal is what cuts off your sixth finger and your tail..."  --Siobhan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Proper place for everything

[Aahz]

In article <509441cb$0$29967$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano   wrote:
>On Fri, 02 Nov 2012 04:20:20 -0700, Jason Benjamin wrote:
>>
>> Anybody know of the appropriate place to troll and flame about various
>> Python related issues?  I'm kind of mad about some Python stuff and I
>> need a place to vent where people may or may not listen, but at at least
>> respond.  Thought this would be a strange question, but I might as well
>> start somewhere.
>
>Thank you for your honesty, but trolling is not welcome.
>
>However if you have actual issues about Python, either pro or con, and 
>hope to have a serious, respectful dialog where both parties listen to 
>each other, feel free to raise them here. Keep in mind three things:
>
>- We've probably heard all your arguments a thousand times before. It's
>  unlikely that you are either the first or the last person to notice
>  that (e.g.) Python has significant indentation. So expect a certain
>  amount of brusqueness.
>
>- If your argument boils down to "Python isn't "
>  we will not be sympathetic, and will probably sneer or laugh at you
>  privately. And possibly publicly too.
>
>- If you hope to convince the Python community to change ,
>  we are constrained by backwards-compatibility issues, policies, and
>  design decisions. Frequently there are (mis-)features that we simply
>  have to live with, for good or ill.

You forgot the fourth point.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"Normal is what cuts off your sixth finger and your tail..."  --Siobhan
-- 
http://mail.python.org/mailman/listinfo/python-list

who can give me some practical tutorials on django 1.4 or 1.5?

[Levi Nie]

Who can give me some practical tutorials on django 1.4 or 1.5?
Thank you.
-- 
http://mail.python.org/mailman/listinfo/python-list