Re: Python is readable

[MRAB]

On 23/03/2012 04:16, Steve Howell wrote:

On Mar 22, 8:20 pm, rusi  wrote:

 On Mar 23, 7:42 am, Steve Howell  wrote:

 >  Do you think we'll always have a huge number of incompatible
 >  programming languages?  I agree with you that it's a fact of life in
 >  2012, but will it be a fact of life in 2062?

 It will be a fact of life wherever Godels theorem is; which put
 simplistically is: consistency and completeness cannot coexist.  This
 is the 'logic-generator' for the mess in programming languages.
 Put in more general terms:
 Completeness is an 'adding' process
 Consistency is a 'subtracting' process
 Running the two together, convergence is hopeless.


Fair enough, but I don't think you can blame Godel's Theorem for the
fact that JS, Ruby, Perl, and PHP all solve basically the same
problems as Python in 2012.  Can't we agree that at least *Perl* is
redundant, and that the lingering existence of Perl 5 is an artifact
of culture, legacy, and primitive experimentation (by future
standards), not mathematical inevitability?


Perl's support for Unicode is much better than the others.


 In programming language terms the pull is between simplicity and
 expressivity/power.


Sure, you can see this tension between Python (simplicity) and Ruby
(expressivity).  My idea of progress--way before 2062--is that you'd
still have a spectrum of simplicity and expressivity, but the level of
elegance and power throughout the spectrum would be elevated.  There
wouldn't be a monoculture, but the cream would eventually rise toward
the top.


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

Re: Python is readable

[Nathan Rice]

>> Do you think we'll always have a huge number of incompatible
>> programming languages?  I agree with you that it's a fact of life in
>> 2012, but will it be a fact of life in 2062?
>
> It will be a fact of life wherever Godels theorem is; which put
> simplistically is: consistency and completeness cannot coexist.  This
> is the 'logic-generator' for the mess in programming languages.
> Put in more general terms:
> Completeness is an 'adding' process
> Consistency is a 'subtracting' process
> Running the two together, convergence is hopeless.

This isn't exactly correct.  The incompleteness theorem basically
shows that in a sufficiently expressive system, there are statements
in the system that cannot be proven given the language of that system.
 We live with this already given the fact that the incompleteness
theorem is closely related to Turing's halting problem.  That doesn't
indicate anything about the convergence of programming languages.  It
does say that we will need some form of unit testing or restricted
subset simulation system as an adjunct to formal verification in most
cases, until the end of time.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python is readable

[Steve Howell]

On Mar 22, 8:20 pm, rusi  wrote:
> On Mar 23, 7:42 am, Steve Howell  wrote:
>
> > Do you think we'll always have a huge number of incompatible
> > programming languages?  I agree with you that it's a fact of life in
> > 2012, but will it be a fact of life in 2062?
>
> It will be a fact of life wherever Godels theorem is; which put
> simplistically is: consistency and completeness cannot coexist.  This
> is the 'logic-generator' for the mess in programming languages.
> Put in more general terms:
> Completeness is an 'adding' process
> Consistency is a 'subtracting' process
> Running the two together, convergence is hopeless.

Fair enough, but I don't think you can blame Godel's Theorem for the
fact that JS, Ruby, Perl, and PHP all solve basically the same
problems as Python in 2012.  Can't we agree that at least *Perl* is
redundant, and that the lingering existence of Perl 5 is an artifact
of culture, legacy, and primitive experimentation (by future
standards), not mathematical inevitability?

> In programming language terms the pull is between simplicity and
> expressivity/power.

Sure, you can see this tension between Python (simplicity) and Ruby
(expressivity).  My idea of progress--way before 2062--is that you'd
still have a spectrum of simplicity and expressivity, but the level of
elegance and power throughout the spectrum would be elevated.  There
wouldn't be a monoculture, but the cream would eventually rise toward
the top.






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

Re: Python is readable

[rusi]

On Mar 23, 7:42 am, Steve Howell  wrote:

> Do you think we'll always have a huge number of incompatible
> programming languages?  I agree with you that it's a fact of life in
> 2012, but will it be a fact of life in 2062?

It will be a fact of life wherever Godels theorem is; which put
simplistically is: consistency and completeness cannot coexist.  This
is the 'logic-generator' for the mess in programming languages.
Put in more general terms:
Completeness is an 'adding' process
Consistency is a 'subtracting' process
Running the two together, convergence is hopeless.

In programming language terms the pull is between simplicity and
expressivity/power.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Number of languages known [was Re: Python is readable] - somewhat OT

[Steve Howell]

On Mar 22, 12:14 pm, Chris Angelico  wrote:
> On Fri, Mar 23, 2012 at 4:44 AM, Steven D'Aprano
>
>  wrote:
> > The typical developer knows three, maybe four languages
> > moderately well, if you include SQL and regexes as languages, and might
> > have a nodding acquaintance with one or two more.
>
> I'm not entirely sure what you mean by "moderately well", nor
> "languages", but I'm of the opinion that a good developer should be
> able to learn a new language very efficiently. Do you count Python 2
> and 3 as the same language? What about all the versions of the C
> standard?
>

Not only is it hard to define what we precisely mean when we say
"[knows] moderately well" or "[n number of] languages", but what in
the world are we talking about with respect to "the typical
developer"?  How do we even begin to define that term?



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

Re: Number of languages known [was Re: Python is readable] - somewhat OT

[Steve Howell]

On Mar 22, 6:11 pm, Steven D'Aprano  wrote:
> On Fri, 23 Mar 2012 06:14:46 +1100, Chris Angelico wrote:
> > In any case, though, I agree that there's a lot of people professionally
> > writing code who would know about the 3-4 that you say. I'm just not
> > sure that they're any good at coding, even in those few languages. All
> > the best people I've ever known have had experience with quite a lot of
> > languages.
>
> I dare say that experience with many languages is a good thing, but it's
> not a prerequisite for mastery of a single language.
>
> In any case, I'm not talking about the best developers. I'm talking about
> the typical developer, who by definition is just average. They probably
> know reasonably well one to three of the half dozen most popular
> languages (VB, Java, C, C+, Javascript, PHP, Perl?) plus regexes and SQL,
> and are unlikely to know any of Prolog, Lisp, Haskell, Hypertalk,
> Mercury, Cobra, Smalltalk, Ada, APL, Emerald, Inform, Forth, ...

I love how you can rattle off 20 or so languages, just off the top of
your head, and not even mention Ruby. ;)

(Although Perl was close enough.)





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

Re: Python is readable

[Steve Howell]

On Mar 22, 10:44 am, Steven D'Aprano  wrote:
> On Thu, 22 Mar 2012 10:29:48 -0400, Nathan Rice wrote:
>
> Or at least before *I* black out. Even if somebody manages to write your
> meta-language, you're going to run into the problem of who is going to be
> able to use it. The typical developer knows three, maybe four languages
> moderately well, if you include SQL and regexes as languages, and might
> have a nodding acquaintance with one or two more.
>

Maybe I'm not the typical developer, but I think "three, maybe four"
is a very low estimate of the number of languages that the typical
developer confronts in his lifetime.  Just in the last couple weeks
I've looked at code in all these languages:

  Python2
  PHP
  JavaScript
  CoffeeScript
  C
  Perl
  Shell (bash)
  Regex (three variants--bash, Python, PHP)
  awk (albeit trivially)
  SQL (two variants--MySQL and Hive)
  HTML
  CSS

With the exception of awk, I know all of the above languages in some
depth, way beyond a "nodding acquaintance."  I'm not taking any sides
on the meta-language debate in pointing this out; I'm merely
suggesting that we do live in a bit of a Tower of Babel.  I'm only
arguing with the numbers in your premise; maybe even if you
underestimate the number of languages that typical devs consume in
2012, you could still draw the same valid conclusions overall with a
slightly more accurate estimate.


> There are a huge number of incompatible programming languages because
> language designers have different requirements, preferences, and styles;
> and because the state of the art of language design is very different in
> 2012 than it was in 1962.

Do you think we'll always have a huge number of incompatible
programming languages?  I agree with you that it's a fact of life in
2012, but will it be a fact of life in 2062?


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

Re: Number of languages known [was Re: Python is readable] - somewhat OT

[Steven D'Aprano]

On Fri, 23 Mar 2012 06:14:46 +1100, Chris Angelico wrote:

> On Fri, Mar 23, 2012 at 4:44 AM, Steven D'Aprano
>  wrote:
>> The typical developer knows three, maybe four languages moderately
>> well, if you include SQL and regexes as languages, and might have a
>> nodding acquaintance with one or two more.
> 
> I'm not entirely sure what you mean by "moderately well", 

I mean more than "poorly" but less than "very well".

Until somebody invents a universal, objective scale for rating relative 
knowledge in a problem domain (in this case, knowledge of a programming 
language), we're stuck with fuzzy quantities like "guru", "expert", "deep 
and complete knowledge of the language and its idioms", all the way down 
to "can write Hello World" and "never used or seen the language before".

Here's a joke version:

http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html


and here's a more serious version:

http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer


> nor
> "languages", but I'm of the opinion that a good developer should be able
> to learn a new language very efficiently. 

Should be, absolutely. Does, perhaps not. Some good developers spend 
their entire life working in one language and have become expert on every 
part of it. Some learn twenty different languages, and barely get beyond 
"Hello World" in any of them.


> Do you count Python 2 and 3 as the same language? 

Absolutely.


> What about all the versions of the C standard?

Probably. I'm not familiar with the C standard.


> In any case, though, I agree that there's a lot of people professionally
> writing code who would know about the 3-4 that you say. I'm just not
> sure that they're any good at coding, even in those few languages. All
> the best people I've ever known have had experience with quite a lot of
> languages.

I dare say that experience with many languages is a good thing, but it's 
not a prerequisite for mastery of a single language.

In any case, I'm not talking about the best developers. I'm talking about 
the typical developer, who by definition is just average. They probably 
know reasonably well one to three of the half dozen most popular 
languages (VB, Java, C, C+, Javascript, PHP, Perl?) plus regexes and SQL, 
and are unlikely to know any of Prolog, Lisp, Haskell, Hypertalk, 
Mercury, Cobra, Smalltalk, Ada, APL, Emerald, Inform, Forth, ... 

Or even in most cases *heard* of them.


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

Re: Best way to disconnect from ldap?

[Tycho Andersen]

On Thu, Mar 22, 2012 at 05:26:11PM +, Steven D'Aprano wrote:
> On Thu, 22 Mar 2012 08:14:47 -0500, Tycho Andersen wrote:
> 
> > I've had similar experiences. In fact, in light of all this - why does
> > __del__ exist at all? Novice python users may (reasonably) assume it
> > behaves similarly to a C++ destructor (even though the docs warn
> > otherwise).
> 
> What makes you think that novice Python users will be familiar with C++ 
> destructors?

I don't, really. It's just natural to assume that __del__ is the
"opposite" of __init__, when it's really not (i.e. every object is
__init__ed, but not every object is destructed and thus __del__'d).
Novice programmers may make this assumption (indeed, many experienced
programmers do as well).

> Be careful about assuming that idioms in  
> will be shared by all Python programmers, novice or expert.

Yeah, C++ was the first language which has destructors that came to
mind. It's certainly not my favorite ;-)

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

Re: Odd strip behavior

[Ian Kelly]

On Thu, Mar 22, 2012 at 1:48 PM, Rodrick Brown  wrote:
> Why wasnt the t removed ?

Because str.strip() only removes leading or trailing characters.  If
you want to remove all the t's, use str.replace:

'this is a test'.replace('t', '')

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Odd strip behavior

[Arnaud Delobelle]

On 22 March 2012 20:04, Rodrick Brown  wrote:
>
> On Mar 22, 2012, at 3:53 PM, Arnaud Delobelle  wrote:
> Try help(ste.strip)
>
> It clearly states "if chars is given and not None, remove characters in
> chars instead.
>
> Does it mean remove only the first occurrence of char? That's the behavior
> I'm seeing.

The key words in the docstring are "leading and trailing"

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

Re: Odd strip behavior

[Rodrick Brown]

On Mar 22, 2012, at 3:53 PM, Arnaud Delobelle  wrote:

> 
> On Mar 22, 2012 7:49 PM, "Rodrick Brown"  wrote:
> >
> > #!/usr/bin/python
> >
> > def main():
> >
> >str1='this is a test'
> >str2='t'
> >
> >print "".join([ c for c in str1 if c not in str2 ])
> >print(str1.strip(str2))
> >
> > if __name__ == '__main__':
> >main()
> >
> > ./remove_str.py
> > his is a es
> > his is a tes
> >
> > Why wasnt the t removed ?
> 
> Try help(ste.strip)
> 

It clearly states "if chars is given and not None, remove characters in chars 
instead. 

Does it mean remove only the first occurrence of char? That's the behavior I'm 
seeing. 
> -- 
> Arnaud
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Odd strip behavior

[Daniel Steinberg]

strip() removes leading and trailing characters, which is why the 't' in 
the middle of the string was not removed. To remove the 't' in the 
middle, str1.replace('t','') is one option.


On 3/22/12 3:48 PM, Rodrick Brown wrote:

#!/usr/bin/python

def main():

 str1='this is a test'
 str2='t'

 print "".join([ c for c in str1 if c not in str2 ])
 print(str1.strip(str2))

if __name__ == '__main__':
 main()

./remove_str.py
his is a es
his is a tes

Why wasnt the t removed ?
Sent from my iPhone



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

Re: Odd strip behavior

[Kiuhnm]

On 3/22/2012 20:48, Rodrick Brown wrote:

#!/usr/bin/python

def main():

 str1='this is a test'
 str2='t'

 print "".join([ c for c in str1 if c not in str2 ])
 print(str1.strip(str2))

if __name__ == '__main__':
 main()

./remove_str.py
his is a es
his is a tes

Why wasnt the t removed ?


Because it's not a leading or trailing character.

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

RE: Odd strip behavior

[Prasad, Ramit]

> str1='this is a test'
> str2='t'
> 
> print "".join([ c for c in str1 if c not in str2 ])
> print(str1.strip(str2))
> 
> if __name__ == '__main__':
> main()
> 
> ./remove_str.py
> his is a es
> his is a tes
> 
> Why wasnt the t removed ?

This is not odd behavior, you just do not understand what
strip does. :)

The behavior is listed on the API. I highly recommend you 
take time to become familiar with it. 


http://docs.python.org/library/stdtypes.html#string-methods
str.strip([chars])
Return a copy of the string with the leading and trailing characters 
removed. The chars argument is a string specifying the set of characters to be 
removed. If omitted or None, the chars argument defaults to removing 
whitespace. The chars argument is not a prefix or suffix; rather, all 
combinations of its values are stripped:
>>>
>>> '   spacious   '.strip()
'spacious'
>>> 'www.example.com'.strip('cmowz.')
'example'


Changed in version 2.2.2: Support for the chars argument.

Ramit


Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423

--


> -Original Message-
> From: python-list-bounces+ramit.prasad=jpmorgan@python.org
> [mailto:python-list-bounces+ramit.prasad=jpmorgan@python.org] On Behalf
> Of Rodrick Brown
> Sent: Thursday, March 22, 2012 2:49 PM
> To: python-list@python.org
> Subject: Odd strip behavior
> 
> #!/usr/bin/python
> 
> def main():
> 
> Sent from my iPhone
> --
> http://mail.python.org/mailman/listinfo/python-list
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.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Odd strip behavior

[Arnaud Delobelle]

On Mar 22, 2012 7:49 PM, "Rodrick Brown"  wrote:
>
> #!/usr/bin/python
>
> def main():
>
>str1='this is a test'
>str2='t'
>
>print "".join([ c for c in str1 if c not in str2 ])
>print(str1.strip(str2))
>
> if __name__ == '__main__':
>main()
>
> ./remove_str.py
> his is a es
> his is a tes
>
> Why wasnt the t removed ?

Try help(ste.strip)

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

Re: Python is readable

[Chris Angelico]

On Fri, Mar 23, 2012 at 6:33 AM, Nathan Rice
 wrote:
> Pipes do not provide any fine grained control over the concurrent
> behavior.  If you want to change the order of calls...

And to clarify: The "order of calls" in what I described is merely the
order of initialization. It's like the order of your imports at the
top of a Python script, and should have equally no significance. And a
module can import other modules by dropping to another chain of pipes
in exactly the same way. It'd work! I can't vouch for performance, of
course...

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

Odd strip behavior

[Rodrick Brown]

#!/usr/bin/python
 
def main():
 
str1='this is a test'
str2='t'
 
print "".join([ c for c in str1 if c not in str2 ])
print(str1.strip(str2))
 
if __name__ == '__main__':
main()
 
./remove_str.py
his is a es
his is a tes

Why wasnt the t removed ?
Sent from my iPhone
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python is readable

[Chris Angelico]

On Fri, Mar 23, 2012 at 6:33 AM, Nathan Rice
 wrote:
> Pipes do not provide any fine grained control over the concurrent
> behavior.  If you want to change the order of calls, suddenly you have
> to write a bash script (with its own set of issues), etc.

Go back to my original post. I posited a means of communication which
allows one module to "call" a function in another module, purely by
writing to stdout. All four (or however many) modules would run
concurrently, and be waiting on stdin most of the time. Of course, the
same technique could be used for true concurrency; with such a simple
message-passing technique, there's no reason to wait for your response
before continuing.

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

Re: Python is readable

[Nathan Rice]

>> For example, your ability to reason about the behavior of the system
>> you posited as a whole is limited.  Are there parts of the different
>> modules that can execute concurrently?  Is the output of module1
>> guaranteed to be acceptable as the input for module2?  Is part of
>> module3 redundant (and thus avoidable) given some conditions in
>> module1?  If you make a change in module2 what effect does that have
>> on module3 and module4?  What if you need to go back and forth between
>> module2 and module3 until some criterion is met before you transition
>> to module4?  What if you sometimes want to run module2b instead of
>> module2?
>
> Pipes allow different modules to execute concurrently (except on DOS
> and maybe Windows, haven't checked). Nothing in ANY language
> "guarantees" acceptable input, but protocolling would do that for you.
> If part of module3 is redundant, you don't call it. If you make a
> change to one that affects others, then you fix the others, same as in
> any other coding system (or non-coding system - if you upgrade your
> hardware from an 8086 with 1MB of memory to a modern box with >4GB,
> you'll have to rewrite your code to take advantage of it). The
> (somewhat stupid) protocol I suggested allows you to go between 2 and
> 3 before going to 4. If you want module2b, you add it to the chain and
> call on it.
>
> Yep, Unix solved all your problems back in the 1970s.

Pipes do not provide any fine grained control over the concurrent
behavior.  If you want to change the order of calls, suddenly you have
to write a bash script (with its own set of issues), etc.

Unix solved these problems in much the same way that the evolution of
appendages solved the problem of changing location from one point to
another before the automobile.  The process matters.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Best way to disconnect from ldap?

[Terry Reedy]

On 3/22/2012 1:54 PM, Tim Chase wrote:

On 03/22/12 12:26, Steven D'Aprano wrote:

On Thu, 22 Mar 2012 08:14:47 -0500, Tycho Andersen wrote:

Given that you can't trust __del__, is there a legitimate
use case for it?


It is part of original or early Python and pretty well superceded by 
cyclic gc (which does not work for object with __del__ *because* of the 
unreliability), explicit close methods, and now context managers.


I've never found the need to write one.


I've found the need to write them...then been frustrated by things
falling out of namespace reach, and found that context managers do a
much more reliable/understandable job, saving what little sanity I had
left. ;-)


Which is one reason they were added ;-).


So I'd say that __del__ was really only useful (for some sick, sick
definition of "useful") in versions of Python before context-managers
were readily available.


And before cyclic gc, which does a better job of ordering deletions.

--
Terry Jan Reedy

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

Re: Python is readable

[Chris Angelico]

On Fri, Mar 23, 2012 at 1:29 AM, Nathan Rice
 wrote:
> For example, your ability to reason about the behavior of the system
> you posited as a whole is limited.  Are there parts of the different
> modules that can execute concurrently?  Is the output of module1
> guaranteed to be acceptable as the input for module2?  Is part of
> module3 redundant (and thus avoidable) given some conditions in
> module1?  If you make a change in module2 what effect does that have
> on module3 and module4?  What if you need to go back and forth between
> module2 and module3 until some criterion is met before you transition
> to module4?  What if you sometimes want to run module2b instead of
> module2?

Pipes allow different modules to execute concurrently (except on DOS
and maybe Windows, haven't checked). Nothing in ANY language
"guarantees" acceptable input, but protocolling would do that for you.
If part of module3 is redundant, you don't call it. If you make a
change to one that affects others, then you fix the others, same as in
any other coding system (or non-coding system - if you upgrade your
hardware from an 8086 with 1MB of memory to a modern box with >4GB,
you'll have to rewrite your code to take advantage of it). The
(somewhat stupid) protocol I suggested allows you to go between 2 and
3 before going to 4. If you want module2b, you add it to the chain and
call on it.

Yep, Unix solved all your problems back in the 1970s.

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

Number of languages known [was Re: Python is readable] - somewhat OT

[Chris Angelico]

On Fri, Mar 23, 2012 at 4:44 AM, Steven D'Aprano
 wrote:
> The typical developer knows three, maybe four languages
> moderately well, if you include SQL and regexes as languages, and might
> have a nodding acquaintance with one or two more.

I'm not entirely sure what you mean by "moderately well", nor
"languages", but I'm of the opinion that a good developer should be
able to learn a new language very efficiently. Do you count Python 2
and 3 as the same language? What about all the versions of the C
standard?

In any case, though, I agree that there's a lot of people
professionally writing code who would know about the 3-4 that you say.
I'm just not sure that they're any good at coding, even in those few
languages. All the best people I've ever known have had experience
with quite a lot of languages.

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

Re: Python is readable

[Chris Angelico]

On Fri, Mar 23, 2012 at 5:26 AM, Nathan Rice
 wrote:
[regarding Python 2 -> 3]
> The extremely slow uptake?  I don't really care one way or another but
> a lot of the devs have lamented the issue.

By your plan, the slow uptake would be accepted, even encouraged. In
fact, your plan is effectively equivalent to simply having both Python
2 and Python 3 installed on every computer, plus having some way for
them to interact.

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

Re: Compiling Python (modules) on 64bit Windows - which compiler suite?

[Ralph Heinkel]

> 
> See "Compiling 64-bit extension modules on Windows" at 
> . It applies to 
> non-Cython extensions as well.
> 
> MinGW-w64 also works, but you'll have to generate and use libpythonXX.a and 
> libmsvcr90.a link libraries.
> 
> Christoph

Thanks to everyone who has replied to my question.
Especially for the link/hint to use the .NET SDK which indeed seems to provide 
the right tools for 64bit compilation.
I'm going to try this and report back here.

Cheers,

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

Re: Python is readable

[Nathan Rice]

>> There is a concept in statistical/mathematical modeling called minimum
>> message length (a close analog is minimum description length), which
>> asserts that the optimum model for some set of information is the one
>> that minimizes the sum of the length of the model and the length of the
>> set described by that model.
>
> (1) Optimum in what sense?

Oh, I don't know, the information theoretic one?  Of course, if you're
part of the department of redundancy department, that might seem to
appear to look like a poor, weak, sub-optimal criterion for the
purposes of evaluation of optimality, goodness and positive quality.

If you're getting hung up on the fact that there are deep ties to data
compression in this language, let me help you out.  Imagine that
instead of having a simple Boolean algebra of two values, the possible
values ranged over a set of elementary concepts.  You are then trying
to come up with a set of compound concepts and a permutation of those
concepts that can describe

> (2) What does this have to do with designing programming languages?

A program is a representation of knowledge (i.e. a model) which a
machine has the ability to interpret.  Let me know if you can't
understand this, I'll break it down further for you.

> This discussion sounds to me like the apocryphal story about the
> spherical cow.
>
> http://en.wikipedia.org/wiki/Spherical_cow

When you take the baton, you're supposed to keep running along the
path in the same direction as the person who handed it to you.

>> Clearly no model is going to be optimal
>> for every set of information.  What I was alluding to in the post that
>> Steve Howell replied to was that we need to have a programming language
>> that is a model of models, then include a second order model as part of
>> the program.  Having one core language with many DSLs that can
>> interoperate is infinitely better than having many languages that
>> cannot.
>
> Some people, when confronted with a problem, think "I know, I'll use a
> DSL." Now they have two problems.

Sure.  When confronted with the problem of finding the area under a
curve, using integral calculus is going to make things worse...  I
should just manually sum the infantesimals, from now until the end of
time.

> And some people think "I know, I'll use a meta-language with an infinite
> number of infinitely variable DSLs." Now they have an infinite number of
> problems.

I'll agree with you, if we change that statement to say "an infinite
number of possible problems, all isomorphic to each other."

>> A language designed in such a way would also prevent issues
>> like the Python 2 -> 3 fiasco,
>
> What fiasco?

The extremely slow uptake?  I don't really care one way or another but
a lot of the devs have lamented the issue.

> You've just lost an awful lot of credibility with me.

I didn't lose anything, technically you lost some of your belief in my
credibility.

So, tautologically, you are the one that lost in this situation.

> I'm just surprised you didn't manage to fit quantum mechanics and "the
> interconnectedness of all things" into it :)

Math/Logic are encompassing.  I could draw analogies to quantum theory
if you really wanted (category theory is great for this sort of
thing).  As for the interconnectedness of all things, that is quack
language, I do science.

>> TL;DR there are a huge number of incompatible programming languages
>> because people are modeling a permutation rather than the input to a
>> permutation generating function.
>
> No offence Nathan, but I think you need to come back down to earth for
> air before you black out:
>
> http://www.joelonsoftware.com/articles/fog18.html

I read that article a long time ago, it was bullshit then, it is
bullshit now.  The only thing he gets right is that the Shannon
information of a uniquely specified program is proportional to the
code that would be required to generate it.  Never mind that if a
program meets a specification, you shouldn't care about any of the
values used for unspecified parts of the program.  If you care about
the values, they should be specified.  So, if Joel had said that the
program was uniquely specified, or that none of the things that
weren't specified require values in the programming language, he might
have been kinda, sorta right.  Of course, nobody cares enough to
specify every last bit of minutiae in a program, and specifications
change, so it is pretty much impossible to imagine either case ever
actually occurring.

> Or at least before *I* black out. Even if somebody manages to write your
> meta-language, you're going to run into the problem of who is going to be
> able to use it. The typical developer knows three, maybe four languages
> moderately well, if you include SQL and regexes as languages, and might
> have a nodding acquaintance with one or two more.

Please don't black out Steven.  I'm trying to encourage thought in
interesting directions; you can't think when you're unconscious.

Lets

Re: Python classes: Simplify?

[J. Cliff Dyer]

The issue of explicitly naming a "self" parameter has been discussed in
depth on a number of occasions.  I recommend a google search for "python
implicit self" for some of the reasons why it exists.  Here's what Guido
has to say about it:

http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

Cheers,
Cliff



On Thu, 2012-03-22 at 13:15 +, Andrea Crotti wrote:
> On 03/22/2012 10:51 AM, Steven Lehar wrote: 
> > It seems to me that the Python class system is needlessly confusing.
> > Am I missing something? 
> > 
> > 
> > For example in the class Complex given in the documentation
> > 
> > 
> > class Complex:
> > def __init__(self, realpart, imagpart):
> > self.r = realpart
> > self.i = imagpart
> > 
> > 
> > x = Complex(3.0, -4.5)
> > 
> > 
> > I initially found it profoundly confusing that __init__( ) calls for
> > 3 arguments, but you call Complex( ) with 2. Furthermore, why not
> > call the initialization function after the class name as is done in
> > other languages? Isn't that the simplest conceptually? Demonstrating
> > with the above example:
> > 
> > 
> > class Complex:
> > def Complex(realpart, imagpart):
> > Complex.r = realpart
> > Complex.i = imagpart
> > 
> > 
> > x = Complex(3.0, -4.5)
> > 
> > 
> > Is there a good reason why classes cannot be defined that way?
> > (Besides the problem of backward-compatibility)
> > 
> > 
> 
> Some time ago I saw some nasty hack that allowed you to drop the self
> in the method declaration,
> using some crazy metaclass trick, but that's really not a good idea ;)
> 
> I agree that is counter-intuitive but just set your editor to do that
> for you and you will be fine..
> 
> in my emacs
> - s TAB -> self
> - . TAB -> self.
> - m TAB -> def ${1:method}(self$2):
>  $0
> 
> so I never actually write the self..


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

Re: Best way to disconnect from ldap?

[Tim Chase]

On 03/22/12 12:26, Steven D'Aprano wrote:

On Thu, 22 Mar 2012 08:14:47 -0500, Tycho Andersen wrote:

Given that you can't trust __del__, is there a legitimate
use case for it?


I've never found the need to write one.


I've found the need to write them...then been frustrated by 
things falling out of namespace reach, and found that context 
managers do a much more reliable/understandable job, saving what 
little sanity I had left. ;-)


So I'd say that __del__ was really only useful (for some sick, 
sick definition of "useful") in versions of Python before 
context-managers were readily available.


-tkc



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

Re: Python is readable

[Steven D'Aprano]

On Thu, 22 Mar 2012 10:29:48 -0400, Nathan Rice wrote:

[Snip a load of stuff about the laws of physics, infinity, and of course 
fractals.]

I'm just surprised you didn't manage to fit quantum mechanics and "the 
interconnectedness of all things" into it :)


> TL;DR there are a huge number of incompatible programming languages
> because people are modeling a permutation rather than the input to a
> permutation generating function.

No offence Nathan, but I think you need to come back down to earth for 
air before you black out:

http://www.joelonsoftware.com/articles/fog18.html

Or at least before *I* black out. Even if somebody manages to write your 
meta-language, you're going to run into the problem of who is going to be 
able to use it. The typical developer knows three, maybe four languages 
moderately well, if you include SQL and regexes as languages, and might 
have a nodding acquaintance with one or two more.

With the radical changes you're suggesting, developers would need to be 
able to deal with some arbitrary number of different DSLs, and whatever 
meta-language is used to glue them together.

There are a huge number of incompatible programming languages because 
language designers have different requirements, preferences, and styles; 
and because the state of the art of language design is very different in 
2012 than it was in 1962.


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

Re: Best way to disconnect from ldap?

[Steven D'Aprano]

On Thu, 22 Mar 2012 08:14:47 -0500, Tycho Andersen wrote:

> I've had similar experiences. In fact, in light of all this - why does
> __del__ exist at all? Novice python users may (reasonably) assume it
> behaves similarly to a C++ destructor (even though the docs warn
> otherwise).

What makes you think that novice Python users will be familiar with C++ 
destructors?

Be careful about assuming that idioms in  
will be shared by all Python programmers, novice or expert.


> Given that you can't trust __del__, is there a legitimate use case for
> it?

I've never found the need to write one.



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

Re: Python is readable

[Steven D'Aprano]

On Thu, 22 Mar 2012 08:47:15 -0400, Nathan Rice wrote:

> There is a concept in statistical/mathematical modeling called minimum
> message length (a close analog is minimum description length), which
> asserts that the optimum model for some set of information is the one
> that minimizes the sum of the length of the model and the length of the
> set described by that model.

(1) Optimum in what sense?

(2) What does this have to do with designing programming languages?

This discussion sounds to me like the apocryphal story about the 
spherical cow.

http://en.wikipedia.org/wiki/Spherical_cow


> Clearly no model is going to be optimal
> for every set of information.  What I was alluding to in the post that
> Steve Howell replied to was that we need to have a programming language
> that is a model of models, then include a second order model as part of
> the program.  Having one core language with many DSLs that can
> interoperate is infinitely better than having many languages that
> cannot.

Some people, when confronted with a problem, think "I know, I'll use a 
DSL." Now they have two problems.

And some people think "I know, I'll use a meta-language with an infinite 
number of infinitely variable DSLs." Now they have an infinite number of 
problems.


> A language designed in such a way would also prevent issues
> like the Python 2 -> 3 fiasco, 

What fiasco?

You've just lost an awful lot of credibility with me.


-- 
Steven


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

ANN: Leo 4.10 b1 released

[Edward K. Ream]

Leo 4.10 b1 is now available at: http://sourceforge.net/projects/leo/files/

Leo is a text editor, data organizer, project manager and much more.
http://webpages.charter.net/edreamleo/intro.html

Leo 4.10 contains 9 months of intense work on Leo. Several very
important
features are subtle; you could almost call them Easter Eggs, so please
read
the following notes carefully.

The highlights of Leo 4.10:
--

* Dozens of new and improved features and commands, including...
  - Tab completion now shows all @command & @button nodes.
  - Leo tabs may be detached from the main window.
  - The Open With menu now works.
  - The leoInspect module answers questions about Python code.
  - Leo can highlight the pane containing the focus.
  - The bigdash plugin searches across multiple files.
  - Improved abbreviation capabilities.
  - Improved handling of URL's.
  - Improved editing of non-Leo files.
  - Improvements create "weightless" unit testing.
* Easier installation on MacOS.
* Fixed almost 70 bugs.

The Easter Eggs
---

1. Tab completion now shows all @command & @button nodes.

Put all your common scripts in @command nodes in myLeoSettings.leo.
Typing @c will remind you of the names of these scripts.
You can execute the scripts by name without the "@command-" prefix.

2. Improved abbreviation capabilities.

Virtually any kind of abbreviation is possible. For example, ~a to ã.

3. Improved handling of URL's.

URL's can link to other Leo outlines. Ctrl-Click on nodes or URL's
in body text to activate the URL.

4 Weightless unit testing.

The mantra is edit, alt-4 (run-marked-unit-tests-externally), edit,
alt-4,... Several seemingly innocuous changes made this work without
an
"friction". The result is a remarkable increase in productivity.

Links:
--
Leo:  http://webpages.charter.net/edreamleo/front.html
Forum:http://groups.google.com/group/leo-editor
Download: http://sourceforge.net/projects/leo/files/
Bzr:  http://code.launchpad.net/leo-editor/
Quotes:   http://webpages.charter.net/edreamleo/testimonials.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python is readable

[Steve Howell]

On Mar 22, 7:29 am, Nathan Rice 
wrote:
> On Thu, Mar 22, 2012 at 9:17 AM, Chris Angelico  wrote:
> > On Thu, Mar 22, 2012 at 11:47 PM, Nathan Rice
> >  wrote:
> >> Having one core language with
> >> many DSLs that can interoperate is infinitely better than having many
> >> languages that cannot.  A language designed in such a way would also
> >> prevent issues like the Python 2 -> 3 fiasco, because two versions of
> >> a DSL can be separate, and code can reference them independently while
> >> being able to interoperate.
>
> > This is either utterly impossible, or already available, depending on
> > your point of view.
>
> Of course it is already available.  It is called the laws of physics.
> Everything we know of inter-operates in the context of physical
> reality perfectly.
>
> > To have an infinitely-configurable program, you must make its
> > configuration equivalent to writing code. There is already an
> > infinitely-configurable program in Unix: "gcc config.c; ./a.out" takes
> > a simple-format text file called "config.c" and processes it.
>
> It is true that infinite configuration requires that the configuration
> be specified in the language of the program.  What's the problem?
>
> > You want infinite DSLs? Behold!
>
> > $ ./module1 | ./module2 | ./module3 | ./module4
>
> > Each one has a shebang that tells you what they are (Python 2, Python
> > 3, something else entirely). There's a very strict interoperability
> > protocol between the modules - they pass information around through
> > stdout and stdin. You can write any module in any language, and you
> > can rewrite module1 for Python 3 without affecting any other or the
> > invocation sequence.
>
> It has always been possible to get from one point in space to another
> point in space in finite time.  Was the invention of the automobile
> was redundant and unimportant?  Obviously not, the characteristics of
> the process matter.
>

The funny thing about the "automobile" is that, for all its impact,
it's really just a better horse.

Imagine in 1750 three futurists pondering how people in the future
could solve the problem of physical separation:

  Futurist A: We'll breed a better horse.
  Futurist B: No, we should build a mechanical machine that's faster
than a horse.
  Futurist C: What if we make it so that two people 10,000 miles away
from each other can talk to each other like they're next door?

The ironic thing is that telecommunication was more or less solved in
the late 1800s or so, but in the 21 century, we still talk about
"horsepower" for our people-moving machines.

I think in 2012, when it comes to programming languages, we're still
mostly breeding better horses.  Nothing wrong with that, just an
observation.



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

Re: Python is readable

[Steve Howell]

On Mar 22, 1:56 am, Steven D'Aprano  wrote:
> On Wed, 21 Mar 2012 18:35:16 -0700, Steve Howell wrote:
> > On Mar 21, 11:06 am, Nathan Rice 
> > wrote:
> >> As for syntax, we have a lot of "real" domain specific languages, such
> >> as English, math and logic. They are vetted, understood and useful
> >> outside the context of programming.  We should approach the discussion
> >> of language syntax from the perspective of trying to define a unified
> >> syntactical structure for real these DSLs.    Ideally it would allow
> >> representation of things in a familiar way where possible, while
> >> providing an elegant mechanism for descriptions that cut across domains
> >> and eliminating redundancy/ambiguity.  This is clearly possible, though
> >> a truly successful attempt would probably be a work of art for the
> >> ages.
>
> > If I'm reading you correctly, you're expressing frustration with the
> > state of language syntax unification in 2012.  You mention language in a
> > broad sense (not just programming languages, but also English, math,
> > logic, etc.), but even in the narrow context of programming languages,
> > the current state of the world is pretty chaotic.
>
> And this is a good thing. Programming languages are chaotic because the
> universe of programming problems is chaotic, and the strategies available
> to solve those problems are many and varied.
>
> Different programming languages are good for different things because
> they have been designed to work in different problem/solution spaces.
> Although I dislike C with a passion, I do recognise that it is good for
> when the programmer needs fine control over the smallest details. It is,
> after all, a high-level assembler. Likewise for Forth, which lets you
> modify the compiler and language as you go.
>
> Some languages are optimized for the compiler, some for the writer, and
> some for the reader. So are optimized for numeric work, others for
> database access. Some are Jack-Of-All-Trades. Each language encourages
> its own idioms and ways of thinking about programming.
>
> When it comes to programming, I say, let a thousand voices shout out.
> Instead of imagining a single language so wonderful that every other
> language is overshadowed and forgotten, imagine that the single language
> is the next Java, or C, or even for that matter Python, but whatever it
> is, it's not ideal for the problems you care about, or the way you think
> about them. Not so attractive now, is it?
>

I'm not imagining a world where a single, imperfect programming
language crowds out other useful solutions.

What I am hoping for is a more purposeful diversity.   It would be
great if the top 20 languages in the future had the same expressive
power as say the top 200 do now.  In other words, by the time you
investigated the 21st best language for your needs, it would be
something really interesting and cutting edge, instead of PHP.

It's hard to imagine the *specific* form of progress we'll have in the
future, but I'd imagine that some day we'll have something more
interesting than a best-of-breed Algol derivative dominating the
scene.

> > The optimistic view is that there will be some kind of inflection point
> > around 2020 or so.  I could imagine a perfect storm of good things
> > happening, like convergence on a single browser platform,
>
> You call that a perfect storm of good things. I call that sort of
> intellectual and software monoculture a nightmare.
>
> I want a dozen browsers, not one of which is so common that web designers
> can design for it and ignore the rest, not one browser so common that
> nobody dares try anything new.
>

I don't want a monoculture any more than you do.  When I talk about
"convergence on a single browser platform", the thought was that web
designers might not to have waste brain cycles on IE6 workarounds in
2020; instead, they could be working on actual, cutting edge design.
By "convergence on a single browser platform", I was hoping for
something like the Unix situation that we have now--there's still
competition, there's still innovation around the edges, but you can
generally rely on 90% of the platform to be predictable.


> > nearly
> > complete migration to Python 3, further maturity of JVM-based languages,
> > etc., where the bar gets a little higher from what people expect from
> > languages.  Instead of fighting semicolons and braces, we start thinking
> > bigger.  It could also be some sort of hardware advance, like screen
> > resolutions that are so amazing they let us completely rethink our views
> > on terseness, punctuation, code organization, etc.
>
> And what of those with poor eyesight, or the blind? Are they to be
> excluded from your "bigger" brave new world?

I made my hypothetical advance ("screen resolutions") a little too
narrow and hardware-focused.  What I really meant to imagine is a
world where eyesight and monitors stop being a bottleneck.  Suppose
people with normal eyesight had way, way better mon

RE: urllib.urlretrieve never returns???

[Prasad, Ramit]

> > I just looked at your source file on ActiveState and noticed that
> > you do not import traceback. That is why you are getting the
> > AttributeError. Now you should be getting a much better error
> > once you import it:)
> Nope. That would result in a NameError. After adding "import traceback",
> I still get several AttributeError messages. The traceback should
> contain the exact line number, and a description about what object is
> missing what attribute anyway. My code is pure Python, and under no
> circumstances should it be able to start a blocked call for a system
> library function.

Your code works for me, so the problem should be your system 
and/or network. Try a different Python version? I tested using 2.6.6.
Also, check your proxy or firewall. If you are using Python 2.x 
try using urllib2. 

Ramit


Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423

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.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Condition in C API

[Matt Joiner]

Is there a Condition-like object exposed in the CPython C API? I've
found PyThread_lock_type, but nothing condition-like.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python is readable

[Nathan Rice]

On Thu, Mar 22, 2012 at 9:17 AM, Chris Angelico  wrote:
> On Thu, Mar 22, 2012 at 11:47 PM, Nathan Rice
>  wrote:
>> Having one core language with
>> many DSLs that can interoperate is infinitely better than having many
>> languages that cannot.  A language designed in such a way would also
>> prevent issues like the Python 2 -> 3 fiasco, because two versions of
>> a DSL can be separate, and code can reference them independently while
>> being able to interoperate.
>
> This is either utterly impossible, or already available, depending on
> your point of view.

Of course it is already available.  It is called the laws of physics.
Everything we know of inter-operates in the context of physical
reality perfectly.

> To have an infinitely-configurable program, you must make its
> configuration equivalent to writing code. There is already an
> infinitely-configurable program in Unix: "gcc config.c; ./a.out" takes
> a simple-format text file called "config.c" and processes it.

It is true that infinite configuration requires that the configuration
be specified in the language of the program.  What's the problem?

> You want infinite DSLs? Behold!
>
> $ ./module1 | ./module2 | ./module3 | ./module4
>
> Each one has a shebang that tells you what they are (Python 2, Python
> 3, something else entirely). There's a very strict interoperability
> protocol between the modules - they pass information around through
> stdout and stdin. You can write any module in any language, and you
> can rewrite module1 for Python 3 without affecting any other or the
> invocation sequence.

It has always been possible to get from one point in space to another
point in space in finite time.  Was the invention of the automobile
was redundant and unimportant?  Obviously not, the characteristics of
the process matter.

For example, your ability to reason about the behavior of the system
you posited as a whole is limited.  Are there parts of the different
modules that can execute concurrently?  Is the output of module1
guaranteed to be acceptable as the input for module2?  Is part of
module3 redundant (and thus avoidable) given some conditions in
module1?  If you make a change in module2 what effect does that have
on module3 and module4?  What if you need to go back and forth between
module2 and module3 until some criterion is met before you transition
to module4?  What if you sometimes want to run module2b instead of
module2?

> Problems always come when you want to share data between dissimilar
> modules. There's no single perfect data-transfer protocol that works
> across all languages. What does it mean to "call a function"? If you
> truly want this level of flexibility, the best thing to do is to
> separate sections cleanly. In fact, the pipe system I show above could
> be used that way, although it's stupidly ugly. Everything going on
> stdout/stdin has a two-word dispatch envelope with a from and a to,
> and each module reads a line, and if it's not addressed to it, passes
> it on to stdout. Responses get sent out with their from and to
> reversed. All you need is for the last module's stdout to be linked
> back into the first module's stdin (not sure if you can do that or not
> - it has the feeling of plugging a power strip into itself), and it'll
> work perfectly. Add a bit of boilerplate so that the application
> developers don't see what's happening underneath, and you could
> pretend that dissimilar languages are able to call into each other.
> Doesn't mean it's efficient though!

What is a function?  You could say that it is a sequence of logical
statements that relates some assertion with another.  You can make a
big deal about call by name versus call by value, but it only really
matters on a conceptual level when dealing with infinite objects that
do not have an analytic closure.  You can make a big deal about data
format, but scientists have been communicating using different unit
systems for hundreds of years, I don't see assertions of relationship
between structures as different from unit conversions from imperial to
metric; it's all data.  There are of course a few snags such as
cardinality of the set represented by the integer data type in one
case versus another, but that is a low level detail that would be a
problem if DSLs were embedded in an expressive modelling language.
Data structures ultimately boil down to assertions, assertions about
those assertions and relations between assertions.

> TLDR version: Infinite flexibility means you're doing nothing.

I could address that from a number of ways.  First off, anything that
is Turing complete is basically "infinitely flexible" but the
difference in expressiveness (as measured by the combined length of
the program and its input required to generate some output) varies
over orders of magnitudes.  So, we're actually discussing "infinitely
expressive" though in fact we don't need to appeal to infinity here,
so that is a strawman.  The reason for that is the system in w

Re: Best way to disconnect from ldap?

[Tycho Andersen]

On Thu, Mar 22, 2012 at 06:27:45AM -0700, Chris Rebert wrote:
> On Thu, Mar 22, 2012 at 6:14 AM, Tycho Andersen  wrote:
> > On Wed, Mar 21, 2012 at 04:49:54PM -0500, Tim Chase wrote:
> >> On 03/21/12 15:54, Chris Kaynor wrote:
> >> >As Chris Rebert pointed out, there is no guarantee as to when the
> >> >__del__ method is called. CPython will generally call it immediately,
> >> >however if there are reference cycles it may never call it
> >>
> >> And more maddeningly, modules/objects used/called from within the
> >> __del__ may have already gone out of scope, producing
> >> head-scratching errors.  I've been bitten by this enough times that
> >> I just stopped using __del__ completely.
> >
> > I've had similar experiences. In fact, in light of all this - why does
> > __del__ exist at all? Novice python users may (reasonably) assume it
> > behaves similarly to a C++ destructor (even though the docs warn
> > otherwise).
> >
> > Given that you can't trust __del__, is there a legitimate use case for
> > it?
> 
> Writing resource classes (like `file`) in C? Their __del__()s
> typically involve little/less Python-level stuff and thus less
> paranoia need be exercised.

Sure, but you still have no guarantee that __del__ will ever be
called, so it's a bad idea to rely on it to clean up anything.

> There is somewhat of a perverse incentive in having such last-ditch
> clean-up mechanisms though. "This code seems to work fine without
> `with`, so why bother changing it?"

Yeah, I guess I can see doing something like:
  __del__ = __exit__
but anything beyond that seems risky...

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

Re: Best way to disconnect from ldap?

[Chris Rebert]

On Thu, Mar 22, 2012 at 6:14 AM, Tycho Andersen  wrote:
> On Wed, Mar 21, 2012 at 04:49:54PM -0500, Tim Chase wrote:
>> On 03/21/12 15:54, Chris Kaynor wrote:
>> >As Chris Rebert pointed out, there is no guarantee as to when the
>> >__del__ method is called. CPython will generally call it immediately,
>> >however if there are reference cycles it may never call it
>>
>> And more maddeningly, modules/objects used/called from within the
>> __del__ may have already gone out of scope, producing
>> head-scratching errors.  I've been bitten by this enough times that
>> I just stopped using __del__ completely.
>
> I've had similar experiences. In fact, in light of all this - why does
> __del__ exist at all? Novice python users may (reasonably) assume it
> behaves similarly to a C++ destructor (even though the docs warn
> otherwise).
>
> Given that you can't trust __del__, is there a legitimate use case for
> it?

Writing resource classes (like `file`) in C? Their __del__()s
typically involve little/less Python-level stuff and thus less
paranoia need be exercised.
There is somewhat of a perverse incentive in having such last-ditch
clean-up mechanisms though. "This code seems to work fine without
`with`, so why bother changing it?"

Cheers,
Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python classes: Simplify?

[Andrea Crotti]

On 03/22/2012 10:51 AM, Steven Lehar wrote:
It seems to me that the Python class system is needlessly confusing. 
Am I missing something?


For example in the class Complex given in the documentation

*class Complex:*
*def __init__(self, realpart, imagpart):*
*self.r = realpart*
*self.i = imagpart*
*
*
*x = Complex(3.0, -4.5)*

I initially found it profoundly confusing that __init__( ) calls for 3 
arguments, but you call Complex( ) with 2. Furthermore, why not call 
the initialization function after the class name as is done in other 
languages? Isn't that the simplest conceptually? Demonstrating with 
the above example:


*class Complex:*
*def Complex(realpart, imagpart):*
*Complex.r = realpart*
*Complex.i = imagpart*
*
*
*x = Complex(3.0, -4.5)*
*
*
Is there a good reason why classes cannot be defined that way? 
(Besides the problem of backward-compatibility)




Some time ago I saw some nasty hack that allowed you to drop the self in 
the method declaration,

using some crazy metaclass trick, but that's really not a good idea ;)

I agree that is counter-intuitive but just set your editor to do that 
for you and you will be fine..


in my emacs
- s TAB -> self
- . TAB -> self.
- m TAB -> def ${1:method}(self$2):
 $0

so I never actually write the self..
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python is readable

[Chris Angelico]

On Thu, Mar 22, 2012 at 11:47 PM, Nathan Rice
 wrote:
> Having one core language with
> many DSLs that can interoperate is infinitely better than having many
> languages that cannot.  A language designed in such a way would also
> prevent issues like the Python 2 -> 3 fiasco, because two versions of
> a DSL can be separate, and code can reference them independently while
> being able to interoperate.

This is either utterly impossible, or already available, depending on
your point of view.

To have an infinitely-configurable program, you must make its
configuration equivalent to writing code. There is already an
infinitely-configurable program in Unix: "gcc config.c; ./a.out" takes
a simple-format text file called "config.c" and processes it.

You want infinite DSLs? Behold!

$ ./module1 | ./module2 | ./module3 | ./module4

Each one has a shebang that tells you what they are (Python 2, Python
3, something else entirely). There's a very strict interoperability
protocol between the modules - they pass information around through
stdout and stdin. You can write any module in any language, and you
can rewrite module1 for Python 3 without affecting any other or the
invocation sequence.

Problems always come when you want to share data between dissimilar
modules. There's no single perfect data-transfer protocol that works
across all languages. What does it mean to "call a function"? If you
truly want this level of flexibility, the best thing to do is to
separate sections cleanly. In fact, the pipe system I show above could
be used that way, although it's stupidly ugly. Everything going on
stdout/stdin has a two-word dispatch envelope with a from and a to,
and each module reads a line, and if it's not addressed to it, passes
it on to stdout. Responses get sent out with their from and to
reversed. All you need is for the last module's stdout to be linked
back into the first module's stdin (not sure if you can do that or not
- it has the feeling of plugging a power strip into itself), and it'll
work perfectly. Add a bit of boilerplate so that the application
developers don't see what's happening underneath, and you could
pretend that dissimilar languages are able to call into each other.
Doesn't mean it's efficient though!

TLDR version: Infinite flexibility means you're doing nothing.

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

Re: Best way to disconnect from ldap?

[Tycho Andersen]

On Wed, Mar 21, 2012 at 04:49:54PM -0500, Tim Chase wrote:
> On 03/21/12 15:54, Chris Kaynor wrote:
> >As Chris Rebert pointed out, there is no guarantee as to when the
> >__del__ method is called. CPython will generally call it immediately,
> >however if there are reference cycles it may never call it
> 
> And more maddeningly, modules/objects used/called from within the
> __del__ may have already gone out of scope, producing
> head-scratching errors.  I've been bitten by this enough times that
> I just stopped using __del__ completely.

I've had similar experiences. In fact, in light of all this - why does
__del__ exist at all? Novice python users may (reasonably) assume it
behaves similarly to a C++ destructor (even though the docs warn
otherwise).

Given that you can't trust __del__, is there a legitimate use case for
it?

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

Re: Accessing the files by last modified time

[Neil Cerutti]

On 2012-03-22, Tim Williams  wrote:
> On Mar 22, 7:33?am, Sangeet  wrote:
>> Hi
>>
>> I am new to the python programming language.
>>
>> I've been trying to write a script that would access the last
>> modified file in one of my directories. I'm using Win XP.
>>
>> I saw a similar topic, on the forum before, however the reply
>> using (os.popen) didn't work out for me. I'm not sure whether
>> it was due to syntax errors either.
>>
>> Thanks,
>> Sangeet
>
> Check out os.stat()

I've been using os.path.getmtime, and converting that to a
datetime object using datetime.datetime.fromtimestamp.

Surprisingly, perhaps, this has been working.

According to the docs, to avoid making any assumptiong,  I might
need to do:

tm = os.path.getmtime(apath)
lt = time.localtime(tm)
datetime.datetime(lt.tm_year, lt.tm_mon, lt.tm_mday)

Here's where I'm confused about the functioning of my original
plan. The docs say:

 os.path.getmtime
 [...]  The return value is a number giving the number of seconds
 since the epoch (see the time module). [...]

 classmethod datetime.fromtimestamp
 Return the local date and time corresponding to the POSIX
 timestamp, such as returned by time.time(). [...]

 time.time
 Return the time as a floating point number expressed as seconds
 since the epoch, in UTC. [...]

I'm not completely sure the return type of getmtime and the
argument type of fromtimestamp are really the same or not. I
guess I came to that conclusion some time in the past, and it
does seem to work. It may be a simple case of just different
aspects the exact same type being being highlighted in each
definition.

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

Re: Python is readable

[Nathan Rice]

>> If I'm reading you correctly, you're expressing frustration with the
>> state of language syntax unification in 2012.  You mention language in a
>> broad sense (not just programming languages, but also English, math,
>> logic, etc.), but even in the narrow context of programming languages,
>> the current state of the world is pretty chaotic.
>
> And this is a good thing. Programming languages are chaotic because the
> universe of programming problems is chaotic, and the strategies available
> to solve those problems are many and varied.
>
> Different programming languages are good for different things because
> they have been designed to work in different problem/solution spaces.
> Although I dislike C with a passion, I do recognise that it is good for
> when the programmer needs fine control over the smallest details. It is,
> after all, a high-level assembler. Likewise for Forth, which lets you
> modify the compiler and language as you go.

There is a concept in statistical/mathematical modeling called minimum
message length (a close analog is minimum description length), which
asserts that the optimum model for some set of information is the one
that minimizes the sum of the length of the model and the length of
the set described by that model.  Clearly no model is going to be
optimal for every set of information.  What I was alluding to in the
post that Steve Howell replied to was that we need to have a
programming language that is a model of models, then include a second
order model as part of the program.  Having one core language with
many DSLs that can interoperate is infinitely better than having many
languages that cannot.  A language designed in such a way would also
prevent issues like the Python 2 -> 3 fiasco, because two versions of
a DSL can be separate, and code can reference them independently while
being able to interoperate.

> Some languages are optimized for the compiler, some for the writer, and
> some for the reader. So are optimized for numeric work, others for
> database access. Some are Jack-Of-All-Trades. Each language encourages
> its own idioms and ways of thinking about programming.

The difference between compiler optimized and writer optimized
languages is how many assertions they require about the thing being
modeled to be a "valid" program, given its deductive rules.  Ideally,
the number of assertions should be flexible, and the
interpreter/compiler should try and figure out the best way to
implement it given the information it has.

> When it comes to programming, I say, let a thousand voices shout out.
> Instead of imagining a single language so wonderful that every other
> language is overshadowed and forgotten, imagine that the single language
> is the next Java, or C, or even for that matter Python, but whatever it
> is, it's not ideal for the problems you care about, or the way you think
> about them. Not so attractive now, is it?

I agree about letting a thousand voices shout out, in the context of
an embedding language that guarantees code interoperability.
Additionally, the size of optimal DSLs for different areas is actually
quite small, yet having separate languages for each DSL requires the
user to re-learn common patterns such as collection manipulation, IO,
etc.  Pretty horrible all around.

>> The optimistic view is that there will be some kind of inflection point
>> around 2020 or so.  I could imagine a perfect storm of good things
>> happening, like convergence on a single browser platform,
>
> You call that a perfect storm of good things. I call that sort of
> intellectual and software monoculture a nightmare.

The cores of English and math are pretty much singularly represented.
At more nuanced or abstract levels, there is divergence in order to
simplify the process of describing complicated things.  How would you
like it if linear algebra or algebraic geometry re-invented addition,
multiplication, etc with completely different syntax and semantics
(I'm ignoring non-commutativity of vector space multiplication)

> I want a dozen browsers, not one of which is so common that web designers
> can design for it and ignore the rest, not one browser so common that
> nobody dares try anything new.

How about one browser that is infinitely configurable?  That way if
someone tries something new, you can try it as well without precluding
anything else you already do.

The CLI/JVM provide some flexibility, but they are not the correct
path.  They model the executable machine representations of language,
rather than modeling the meta structure of language.  This means that
you still lack flexibility and dynamism.  At least things are moving
in the right direction.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Accessing the files by last modified time

[Peter Otten]

Sangeet wrote:

> I've been trying to write a script that would access the last modified
> file in one of my directories. I'm using Win XP.

import os
import glob

path = r"c:\one\of\my directories\*"

youngest_file = max(glob.glob(path), key=os.path.getmtime)

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

Re: Accessing the files by last modified time

[Tim Williams]

On Mar 22, 7:33 am, Sangeet  wrote:
> Hi
>
> I am new to the python programming language.
>
> I've been trying to write a script that would access the last modified file 
> in one of my directories. I'm using Win XP.
>
> I saw a similar topic, on the forum before, however the reply using 
> (os.popen) didn't work out for me. I'm not sure whether it was due to syntax 
> errors either.
>
> Thanks,
> Sangeet

Check out os.stat()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Accessing the files by last modified time

[Chris Rebert]

On Thu, Mar 22, 2012 at 4:33 AM, Sangeet  wrote:
> Hi
>
> I am new to the python programming language.
>
> I've been trying to write a script that would access the last modified file 
> in one of my directories. I'm using Win XP.
>
> I saw a similar topic, on the forum before, however the reply using 
> (os.popen) didn't work out for me. I'm not sure whether it was due to syntax 
> errors either.

Recursively or non-recursively?
Live monitoring or just one-time?
What was the forum post in question?

In the simple case, you just need to stitch together these functions:
http://docs.python.org/library/os.html#os.stat
(note the .st_mtime attribute of the result)
http://docs.python.org/library/os.path.html#os.path.join
with one of these functions:
http://docs.python.org/library/os.html#os.listdir
http://docs.python.org/library/os.html#os.walk

Cheers,
Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python is readable (OT)

[Jon Clements]

On Thursday, 22 March 2012 08:56:17 UTC, Steven D'Aprano  wrote:
> On Wed, 21 Mar 2012 18:35:16 -0700, Steve Howell wrote:
> 
> > On Mar 21, 11:06 am, Nathan Rice 
> > wrote:
[snip].
> 
> Different programming languages are good for different things because 
> they have been designed to work in different problem/solution spaces. 
> Although I dislike C with a passion, I do recognise that it is good for 
> when the programmer needs fine control over the smallest details. It is, 
> after all, a high-level assembler. Likewise for Forth, which lets you 
> modify the compiler and language as you go.
> 
> Some languages are optimized for the compiler, some for the writer, and 
> some for the reader. So are optimized for numeric work, others for 
> database access. Some are Jack-Of-All-Trades. Each language encourages 
> its own idioms and ways of thinking about programming. 
> 
> When it comes to programming, I say, let a thousand voices shout out. 
> Instead of imagining a single language so wonderful that every other 
> language is overshadowed and forgotten, imagine that the single language 
> is the next Java, or C, or even for that matter Python, but whatever it 
> is, it's not ideal for the problems you care about, or the way you think 
> about them. Not so attractive now, is it?
> 
> 
> > The optimistic view is that there will be some kind of inflection point
> > around 2020 or so.  I could imagine a perfect storm of good things
> > happening, like convergence on a single browser platform,
> 
> You call that a perfect storm of good things. I call that sort of 
> intellectual and software monoculture a nightmare.
> 
> I want a dozen browsers, not one of which is so common that web designers 
> can design for it and ignore the rest, not one browser so common that 
> nobody dares try anything new.
> 
> 
> > nearly
> > complete migration to Python 3, further maturity of JVM-based languages,
> > etc., where the bar gets a little higher from what people expect from
> > languages.  Instead of fighting semicolons and braces, we start thinking
> > bigger.  It could also be some sort of hardware advance, like screen
> > resolutions that are so amazing they let us completely rethink our views
> > on terseness, punctuation, code organization, etc.
> 
> And what of those with poor eyesight, or the blind? Are they to be 
> excluded from your "bigger" brave new world?
> 
> 
> 
> -- 
> Steven



On Thursday, 22 March 2012 08:56:17 UTC, Steven D'Aprano  wrote:
> On Wed, 21 Mar 2012 18:35:16 -0700, Steve Howell wrote:
> 
> > On Mar 21, 11:06 am, Nathan Rice 
> > wrote:
> >> As for syntax, we have a lot of "real" domain specific languages, such
> >> as English, math and logic. They are vetted, understood and useful
> >> outside the context of programming.  We should approach the discussion
> >> of language syntax from the perspective of trying to define a unified
> >> syntactical structure for real these DSLs.    Ideally it would allow
> >> representation of things in a familiar way where possible, while
> >> providing an elegant mechanism for descriptions that cut across domains
> >> and eliminating redundancy/ambiguity.  This is clearly possible, though
> >> a truly successful attempt would probably be a work of art for the
> >> ages.
> > 
> > If I'm reading you correctly, you're expressing frustration with the
> > state of language syntax unification in 2012.  You mention language in a
> > broad sense (not just programming languages, but also English, math,
> > logic, etc.), but even in the narrow context of programming languages,
> > the current state of the world is pretty chaotic.
> 
> And this is a good thing. Programming languages are chaotic because the 
> universe of programming problems is chaotic, and the strategies available 
> to solve those problems are many and varied.
> 
> Different programming languages are good for different things because 
> they have been designed to work in different problem/solution spaces. 
> Although I dislike C with a passion, I do recognise that it is good for 
> when the programmer needs fine control over the smallest details. It is, 
> after all, a high-level assembler. Likewise for Forth, which lets you 
> modify the compiler and language as you go.
> 
> Some languages are optimized for the compiler, some for the writer, and 
> some for the reader. So are optimized for numeric work, others for 
> database access. Some are Jack-Of-All-Trades. Each language encourages 
> its own idioms and ways of thinking about programming. 
> 
> When it comes to programming, I say, let a thousand voices shout out. 
> Instead of imagining a single language so wonderful that every other 
> language is overshadowed and forgotten, imagine that the single language 
> is the next Java, or C, or even for that matter Python, but whatever it 
> is, it's not ideal for the problems you care about, or the way you think 
> about them. Not so attractive now, is it?
> 
> 
> > The optimistic view is that there

Re: Python classes: Simplify?

[Chris Rebert]

On Thu, Mar 22, 2012 at 3:51 AM, Steven Lehar  wrote:
> It seems to me that the Python class system is needlessly confusing. Am I
> missing something?

Explicit `self` is slightly annoying, but you'll get over it quickly (trust me).

> For example in the class Complex given in the documentation
>
> class Complex:
>     def __init__(self, realpart, imagpart):
>         self.r = realpart
>         self.i = imagpart
>
> x = Complex(3.0, -4.5)
>
> I initially found it profoundly confusing that __init__( ) calls for 3
> arguments, but you call Complex( ) with 2.

That's not at all unique to __init__().

> Furthermore, why not call the
> initialization function after the class name as is done in other languages?

Yech. That would add another step to renaming a class and make
referring to the superclass initializer method rather difficult. It
would also break the "all special methods have underscored names"
rule.

Perhaps you'll find the following instructive:
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
>>> class Foo(object):
... def __init__(self):
... pass
...
>>> Foo()
<__main__.Foo object at 0x100fd5750>
>>> Bar = Foo
>>> Bar.__name__ = "Bar"
>>> del Foo
>>> # look Ma, I've renamed the class!
>>> Bar()
<__main__.Bar object at 0x100fd57d0>

How would your scheme account for this possibility?

> Isn't that the simplest conceptually? Demonstrating with the above example:
>
> class Complex:
>     def Complex(realpart, imagpart):
>         Complex.r = realpart
>         Complex.i = imagpart

Your change of "self" to "Complex" in the method body here makes no sense to me.

> x = Complex(3.0, -4.5)
>
> Is there a good reason why classes cannot be defined that way? (Besides the
> problem of backward-compatibility)

Mostly historical, IMO. But here are some justifications for explicit `self`:
http://docs.python.org/faq/design.html#why-must-self-be-used-explicitly-in-method-definitions-and-calls
http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

Cheers,
Chris R.
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python classes: Simplify?

[Chris Angelico]

On Thu, Mar 22, 2012 at 9:51 PM, Steven Lehar  wrote:
> It seems to me that the Python class system is needlessly confusing. Am I
> missing something?
>
> For example in the class Complex given in the documentation
>
> class Complex:
>     def __init__(self, realpart, imagpart):
>         self.r = realpart
>         self.i = imagpart
>
> x = Complex(3.0, -4.5)
>
> I initially found it profoundly confusing that __init__( ) calls for 3
> arguments, but you call Complex( ) with 2. Furthermore, why not call the
> initialization function after the class name as is done in other languages?
> Isn't that the simplest conceptually? Demonstrating with the above example:

Why doesn't Python do things the way Java does? Because Python isn't
Java. Different language, different choices. :)

Methods are called with an explicit first argument (the object being
acted upon). Constructors need that argument too, even though it's not
given in the invocation. With your example alternate syntax:

> class Complex:
>     def Complex(realpart, imagpart):
>         Complex.r = realpart
>         Complex.i = imagpart

there's no way to distinguish between assigning to the newly-created
object's attributes and assigning to the class's own attributes.
Especially since the latter is a truly viable option in Python, this
can't be done; consequently, there needs to be either an explicit or
an implicit "self" argument (C++ does this with an implicit 'this'
pointer); the Python choice is to make it explicit.

There's really no reason to have the name of the constructor change
when the class is renamed. The way Python does things, you can rename
a class by changing just one thing, the "class Foo:" line. In C++, you
have to also rename all your constructors. And bear in mind, a class
is an object, same as any other:

>>> class Foo:
def __init__(self,x):
self.x=x
def speak(self):
print("x = "+self.x)

>>> a=Foo("Hello")
>>> a.speak()
x = Hello
>>> Bar=Foo
>>> b=Bar("World")
>>> b.speak()
x = World

If the constructor is named the same as the class, how would this sort
of thing function?

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

Python classes: Simplify?

[Steven Lehar]

It seems to me that the Python class system is needlessly confusing. Am I
missing something?

For example in the class Complex given in the documentation

*class Complex:*
*def __init__(self, realpart, imagpart):*
*self.r = realpart*
*self.i = imagpart*
*
*
*x = Complex(3.0, -4.5)*

I initially found it profoundly confusing that __init__( ) calls for 3
arguments, but you call Complex( ) with 2. Furthermore, why not call the
initialization function after the class name as is done in other languages?
Isn't that the simplest conceptually? Demonstrating with the above example:

*class Complex:*
*def Complex(realpart, imagpart):*
*Complex.r = realpart*
*Complex.i = imagpart*
*
*
*x = Complex(3.0, -4.5)*
*
*
Is there a good reason why classes cannot be defined that way? (Besides the
problem of backward-compatibility)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python is readable

[Steven D'Aprano]

On Wed, 21 Mar 2012 18:35:16 -0700, Steve Howell wrote:

> On Mar 21, 11:06 am, Nathan Rice 
> wrote:
>> As for syntax, we have a lot of "real" domain specific languages, such
>> as English, math and logic. They are vetted, understood and useful
>> outside the context of programming.  We should approach the discussion
>> of language syntax from the perspective of trying to define a unified
>> syntactical structure for real these DSLs.    Ideally it would allow
>> representation of things in a familiar way where possible, while
>> providing an elegant mechanism for descriptions that cut across domains
>> and eliminating redundancy/ambiguity.  This is clearly possible, though
>> a truly successful attempt would probably be a work of art for the
>> ages.
> 
> If I'm reading you correctly, you're expressing frustration with the
> state of language syntax unification in 2012.  You mention language in a
> broad sense (not just programming languages, but also English, math,
> logic, etc.), but even in the narrow context of programming languages,
> the current state of the world is pretty chaotic.

And this is a good thing. Programming languages are chaotic because the 
universe of programming problems is chaotic, and the strategies available 
to solve those problems are many and varied.

Different programming languages are good for different things because 
they have been designed to work in different problem/solution spaces. 
Although I dislike C with a passion, I do recognise that it is good for 
when the programmer needs fine control over the smallest details. It is, 
after all, a high-level assembler. Likewise for Forth, which lets you 
modify the compiler and language as you go.

Some languages are optimized for the compiler, some for the writer, and 
some for the reader. So are optimized for numeric work, others for 
database access. Some are Jack-Of-All-Trades. Each language encourages 
its own idioms and ways of thinking about programming. 

When it comes to programming, I say, let a thousand voices shout out. 
Instead of imagining a single language so wonderful that every other 
language is overshadowed and forgotten, imagine that the single language 
is the next Java, or C, or even for that matter Python, but whatever it 
is, it's not ideal for the problems you care about, or the way you think 
about them. Not so attractive now, is it?


> The optimistic view is that there will be some kind of inflection point
> around 2020 or so.  I could imagine a perfect storm of good things
> happening, like convergence on a single browser platform,

You call that a perfect storm of good things. I call that sort of 
intellectual and software monoculture a nightmare.

I want a dozen browsers, not one of which is so common that web designers 
can design for it and ignore the rest, not one browser so common that 
nobody dares try anything new.


> nearly
> complete migration to Python 3, further maturity of JVM-based languages,
> etc., where the bar gets a little higher from what people expect from
> languages.  Instead of fighting semicolons and braces, we start thinking
> bigger.  It could also be some sort of hardware advance, like screen
> resolutions that are so amazing they let us completely rethink our views
> on terseness, punctuation, code organization, etc.

And what of those with poor eyesight, or the blind? Are they to be 
excluded from your "bigger" brave new world?



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

Re: Compiling Python (modules) on 64bit Windows - which compiler suite?

[Stefan Behnel]

Thomas Bach, 21.03.2012 20:03:
> Ralph Heinkel writes:
>> when processing our mass spectrometry data we are running against the
>> 2GB memory limit on our 32 bit machines. So we are planning to move to
>> 64bit. Downloading and installing the 64bit version of Python for
>> Windows is trivial, but how do we compile our own C extension? 
> 
> What about installing Cygwin and using the shipped GCC?

I'm pretty sure it doesn't cross compile to native Windows. It certainly
won't build against a native Windows Python installation, and given the
overhead that cygwin induces into a lot of common OS operations (such as
fork(), I/O operations or file system access), a native Windows Python
installation has serious advantages in most cases.

If the choice is GCC, then MinGW is the right tool.

Stefan

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