Re: Functions vs OOP

[tinnews]

Ian Kelly  wrote:
> On Sat, Sep 3, 2011 at 10:15 AM, William Gill  wrote:
> > During some recent research, and re-familiarization with Python, I came
> > across documentation that suggests that programming using functions, and
> > programming using objects were somehow opposing techniques.
> >
> > It seems to me that they are complimentary.  It makes sense to create
> > objects and have some functions that take those objects as arguments. Are
> > they suggesting that any function that takes an object as an argument should
> > always be a method of that object?  Conversely I can see creating functions
> > that take raw input (e.g. strings) and return it in a format compatible with
> > an object's constructor, rather than have objects accept any conceivable
> > format for its constructor.
> >
> > Am I missing something, or am I taking things too literally?
> 
> I think you may be confusing "functional programming" and "programming
> using functions".  These are not the same thing.
> 
> Functional programming is about using functions in the *mathematical*
> sense.  A mathematical function maps one value (or tuple of values) to
> another value.  The mapped value never varies; if it did, it would be
> a different function.  So functional programming eschews the use of
> functions where the results depend on any internal or external state
> beyond the values of the passed-in arguments, such as the variable
> state of the object the method is being called on.
> 
I think there may be another issue here.  If someone says "functional
programming" to me then I would generally assume that they *do* mean
"programming using functions".  While your distinction of the two may
be strictly correct I don't think it's the generally accepted meaning.

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

Re: Installing WebDAV server

[Fokke Nauta]

"Thomas 'PointedEars' Lahn"  wrote in message 
news:109595831.vcn276c...@pointedears.de...



If you don't have anything better to contribute, please stop answering.

Es genügt schon.

Fokke 


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

Re: Functions vs OOP

[Adam Jorgensen]

Progranming with functions vs Progranming with objects sounds like C vs. C++
more than functional programming vs. OO programming

On 4 September 2011 04:18, William Gill  wrote:

> On 9/3/2011 9:51 PM, Terry Reedy wrote:
>
>>
>> It is possible that our doc was less than crystal clear. We are
>> constantly improving it where we can see fixable faults. If you run
>> across whatever it was and it still seems a bit muddy, post something
>> again.
>>
>>  Will do.
>
> Thanks.
>
> --
> http://mail.python.org/**mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Python-ideas] allow line break at operators

[Yingjie Lan]

>
Thanks, I think that's the rule described in its full glory. Currently I am not 
 quite sure of the use case for continuation nested in continuation -- it seems 
to be still a single continuation, but it allows for some additional freedom in 
formatting the continued line. Do you have other use cases for that?


For the case of mis-indentation, as demonstrated in your scenario, I think it 
is better that the rule is not applied to a comment continued onto the next 
line. The effect of a '#' only carries to the end of a line, if one would like 
the next line to be a comment, just use another '#'. It remains to consider a 
mis-indentation that only involves code lines. However, that is not a new 
problem, so we should not worry (it is like a sunken cost). 

Sorry for top posting. It seems yahoo web email is not designed with such a use 
case in mind.


>
>From: MRAB 
>To: python-list@python.org
>Sent: Sunday, September 4, 2011 10:04 AM
>Subject: Re: [Python-ideas] allow line break at operators
>
>On 04/09/2011 00:22, Yingjie Lan wrote:
>>>  Every language with blocks needs some mechanism to indicate the
>> beginning and ending of blocks and of statements within blocks. If
>> visible fences ('begin/end' or '{}') and statement terminators (';') are
>> used, then '\n' can be treated as merely a space, as it is in C, for
>> instance.
>>>  and it uses unescaped '\n' (with two escapement options) to terminate
>> statements. This is fundamental to Python's design and goes along with
>> significant indents.
>>
>> Agreed. Currently indentation in Python starts a new block, but if you
>> view it from the perspective of line breaking, it also functions as if
>> the line is continued. The line of code below
>>
>> if condition: do_a(); do_b()
>>
>> can be written as:
>>
>> if condition: #line breaks
>> do_a(); # ';' is optional here
>> do_b() # continue
>>
>> That indentation can be also employed for line breaking is quite evident
>> to me. During the open email correspondence with Stephen, it seems to be
>> a tenable point.
>>
>>  > There would then be three ways to escape newline, with one doing
>> double duty. And for what? Merely to avoid using either of the two
>> methods already available.
>>
>> I believe the other two ways are not as good as this new way. As the
>> proposal is fully backward compatible, people may choose whatever way
>> they prefer.
>>
>I think that the rules would be:
>
>If a line ends with a colon and the next line is indented, then it's
>the start of a block, and the following lines which belong to that
>block have the same indent.
>
>If a line doesn't end with a colon but the next line is indented, then
>it's the start of a continuation, and the following lines which belong
>to that continuation have the same indent.
>
>In both cases there could be blocks nested in blocks and possibly
>continuations nested in continuations, as well as blocks nested in
>continuations and continuations nested in blocks.
>
>I'm not sure what the effect would be if you had mis-indented lines.
>For example, if a line was accidentally indented after a comment, then
>it would be treated as part of the comment. It's in cases like those
>that syntax colouring would be helpful. It would be a good idea to use
>an editor which could indicate in some way when a line is a
>continuation.
>
>>     
>>     *From:* Terry Reedy 
>>     *To:* python-list@python.org
>>     *Cc:* python-id...@python.org
>>     *Sent:* Sunday, September 4, 2011 3:01 AM
>>     *Subject:* Re: [Python-ideas] allow line break at operators
>>
>>     On 9/3/2011 3:51 AM, Yingjie Lan wrote:
>>      > I agree that long lines of code are not very common in many projects,
>>      > though it might be the case with some heavily involved in math.
>>     For some
>>      > reason, when the feature of free line breaking came about in computer
>>      > languages, it is welcomed and generally well accepted.
>>
>>     Every language with blocks needs some mechanism to indicate the
>>     beginning and ending of blocks and of statements within blocks. If
>>     visible fences ('begin/end' or '{}') and statement terminators (';')
>>     are used, then '\n' can be treated as merely a space, as it is in C,
>>     for instance.
>>
>>      > Python uses indentation for blocks,
>>
>>     and it uses unescaped '\n' (with two escapement options) to
>>     terminate statements. This is fundamental to Python's design and
>>     goes along with significant indents.
>>
>>      > and by the same mechanism, line breaking can be
>>      > accommodated without requiring parenthesis or ending backslashes.
>>
>>     You need proof for your claim that indentation can be used for both
>>     jobs in the form of a grammar that works with Python's parser. I am
>>     dubious that you can do that with an indents *after* the newline.
>>
>>     Even if you could, it would be confusing 

Re: Need advice on Web / Database framework...

[Alexandru Lazar]

> How does web2py compare to django? I just started playing with django,
> but don't know web2py

I haven't used Django, but I did use web2py for a project that fell on my
head just before leaving my old workplace. I just wanted it to end quickly
so I took web2py as a shortcut.

It's a great framework -- there seems to be an abstraction layer for
anything, so you can write a fairly pythonic web app with it. The app I
had to write was fairly trivial to be sure, and I barely had to write
any code at all.

What I didn't quite like about it was the documentation, that felt rather
sketchy. There's the Official Web2py Book, but that has more of a tutorial
structure. The API reference feels a tad sketchy and I sometimes had to
guess my way around. But there's a good chance that this is just my bad
impression, as I am not a web developer.

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

Re: Functions vs OOP

[Steven D'Aprano]

tinn...@isbd.co.uk wrote:

> I think there may be another issue here.  If someone says "functional
> programming" to me then I would generally assume that they *do* mean
> "programming using functions".  

Strictly speaking you are correct, "functional programming" does
mean "programming using functions", the usual name for which is "procedural
programming". But it means more than that: functions in the sense of
mathematical functions, not merely sub-routines.

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

Merely using functions is not the same as functional programming.

> While your distinction of the two may 
> be strictly correct I don't think it's the generally accepted meaning.

On the contrary, "functional programming" specifically refers to languages
derived from, based on, or at least inspired by, the ideas of Alonzo
Church's lambda calculus. It should be understood as somewhat in opposition
to the idea of imperative programming, where the programmer gives
instructions for changing program state.

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

In practice, there are degrees of purity: strictly speaking, a purely
functional language would be impractical, because it would have no I/O and
therefore not be very useful. But generally, functional programming
implies:

- all coding is done using functions
- functions are first-class data values
- higher-order functions are used (functions which take functions as
arguments)
- no global variables
- all data is immutable (cannot be modified)
- functions should always return the same result each time they are called
with the same arguments (so-called "referential transparency")
- computations should be performed lazily as needed
- no side-effects other than those caused by hardware limitations (e.g.
there is only a finite amount of memory available), usually with an
exemption made for I/O
- use of recursion instead of imperative features such as iteration (for
loops, while loops, etc.)


Pure functional programming languages enforce those conventions as design
features, rather than just leaving it up to the coder to apply them as a
convention. Impure functional languages, such as Python, don't enforce all
(or even any) of those conditions, although they may provide certain
functional features.



-- 
Steven

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

Re: Functions vs OOP

[rusi]

On Sep 3, 9:15 pm, William Gill  wrote:
> During some recent research, and re-familiarization with Python, I came
> across documentation that suggests that programming using functions, and
> programming using objects were somehow opposing techniques.

Staying with (for the moment) the suggestion that OO-P and F-P are
complementary, I believe it is worthwhile to distinguish syntactic OO-
P vs F-P from semantic OO-P vs F-P.

Syntactically: f(x) is functional x.f() is object oriented.
Semantically if f's return value depends only on x ie does not depend
on state it is functional (in the math sense) -- the jargon is that f
is referentially transparent.

Referential opaqueness is usually such a source of problems that it
turns out good to contain the problem somewhat -- hence the wish for
encapsulation.

One can find in the python library itself all 4 combinations:
syntactically and semantically OO : sort
syntactically and semantically FP: sorted
syntactically OO semantically FP: join
-- 
http://mail.python.org/mailman/listinfo/python-list

Can't use subprocess.Popen() after os.chroot() - why?

[Erik]

Hi All,

I'm trying to do the following: 

import os
from subprocess import Popen, PIPE

os.chroot("/tmp/my_chroot")
p = Popen("/bin/date", stdin=PIPE, stdout=PIPE, stderr=PIPE)
stdout_val, stderr_val = p.communicate()
print stdout_val

but the Popen call is dying with the following exception:

Traceback (most recent call last):
  File "./test.py", line 7, in 
p = Popen("/bin/date", stdin=PIPE, stdout=PIPE, stderr=PIPE)
  File "/home/erik/lib/python2.7/subprocess.py", line 679, in __init__
  File "/home/erik/lib/python2.7/subprocess.py", line 1224, in _execute_child
  File "/home/erik/lib/python2.7/pickle.py", line 1382, in loads
  File "/home/erik/lib/python2.7/pickle.py", line 858, in load
  File "/home/erik/lib/python2.7/pickle.py", line 971, in load_string
LookupError: unknown encoding: string-escape

Am I missing something here? does the chroot environment need to be populated 
with more than just the date executable in this case? I can't seem to find any 
examples of this & would appreciate any insight.  

Thanks,
Erik.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can't use subprocess.Popen() after os.chroot() - why?

[Alain Ketterlin]

Erik  writes:

> import os
> from subprocess import Popen, PIPE
>
> os.chroot("/tmp/my_chroot")
> p = Popen("/bin/date", stdin=PIPE, stdout=PIPE, stderr=PIPE)
> stdout_val, stderr_val = p.communicate()
> print stdout_val
>
> but the Popen call is dying with the following exception:
>
> Traceback (most recent call last):
>   File "./test.py", line 7, in 
> p = Popen("/bin/date", stdin=PIPE, stdout=PIPE, stderr=PIPE)
>   File "/home/erik/lib/python2.7/subprocess.py", line 679, in __init__
>   File "/home/erik/lib/python2.7/subprocess.py", line 1224, in _execute_child
>   File "/home/erik/lib/python2.7/pickle.py", line 1382, in loads
>   File "/home/erik/lib/python2.7/pickle.py", line 858, in load
>   File "/home/erik/lib/python2.7/pickle.py", line 971, in load_string
> LookupError: unknown encoding: string-escape
>
> Am I missing something here? does the chroot environment need to be
> populated with more than just the date executable in this case?

Yes, because /bin/date is probably dynamically linked: you need the libs
as well. (Try first with a statically linked executable, e.g.,
/bin/busybox, and everything should be ok).

I agree the message is strange. For some reason, subprocess is calling
pickle.loads, which calls rep.decode("string-escape"), which probably
needs to access some file and fails because of the chroot().

I woud advise to use the chroot command instead of chrooting your python
process, if that's possible for you.

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

Re: allow line break at operators

[rantingrick]

On Sep 3, 11:50 am, Stephen Hansen  wrote:

> Freedom is not and never has been, IMHO, a virtue or goal or even desire
> in Python.

Exactly!

> Where it occurs, it is at best a happy coincidence,

Exactly!

> and even
> if that happy coincidence happens often, it is not a design feature, IMHO.

Exactly! Actually i believe Python allows TOO many freedoms and
indulges TOO many excesses to the detriment of our code bases. Take
the fact that both tabs AND spaces are legal in Python source. We
should have choose one over the other!

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

Re: [Python-ideas] allow line break at operators

[ron3200]

On Sat, 2011-09-03 at 13:38 +0900, Stephen J. Turnbull wrote:
> Guido van Rossum writes:
>  > On Fri, Sep 2, 2011 at 12:28 AM, Stephen J. Turnbull  
> wrote:
> 
>  > > Sure, but IIRC one design principle of Python is that the keyword that
>  > > denotes the syntax should be the first thing on the line,
> [...]
>  > That's true for *statements* (except assignments and calls).
>  > 
>  > > Analogously, if operators are going to denote continuation, they
>  > > should come first on the line.
> 
>  > That doesn't follow.
> 
> Agreed, it's not a logical implication.  The analogy is only an
> analogy, but my eyes do work that way.
> 
> My conclusion is that we shouldn't try to encourage either style,
> because people "see" continuation differently.  Legislating a style
> isn't going to change that, I think.

I like to start continued lines with an operator as well.   I also think
it helps me keep it in my head a bit easier when I do that. 

I think this is one of those areas where computers and people differ,
but it may also depend on the persons native language as to what works
better for them.

Ron



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

Re: Can't use subprocess.Popen() after os.chroot() - why?

[Hans Mulder]

On 4/09/11 17:25:48, Alain Ketterlin wrote:

Erik  writes:


import os
from subprocess import Popen, PIPE

os.chroot("/tmp/my_chroot")
p = Popen("/bin/date", stdin=PIPE, stdout=PIPE, stderr=PIPE)
stdout_val, stderr_val = p.communicate()
print stdout_val

but the Popen call is dying with the following exception:

Traceback (most recent call last):
   File "./test.py", line 7, in
 p = Popen("/bin/date", stdin=PIPE, stdout=PIPE, stderr=PIPE)
   File "/home/erik/lib/python2.7/subprocess.py", line 679, in __init__
   File "/home/erik/lib/python2.7/subprocess.py", line 1224, in _execute_child
   File "/home/erik/lib/python2.7/pickle.py", line 1382, in loads
   File "/home/erik/lib/python2.7/pickle.py", line 858, in load
   File "/home/erik/lib/python2.7/pickle.py", line 971, in load_string
LookupError: unknown encoding: string-escape

Am I missing something here? does the chroot environment need to be
populated with more than just the date executable in this case?


Yes, because /bin/date is probably dynamically linked: you need the libs
as well. (Try first with a statically linked executable, e.g.,
/bin/busybox, and everything should be ok).


/bin/date also needs timezone information from either /etc/localtime
or /usr/share/zoneinfo/ (depends on whether the environment variable
TZ is set).

It may need other data files as well (e.g. for localization).


I agree the message is strange. For some reason, subprocess is calling
pickle.loads, which calls rep.decode("string-escape"), which probably
needs to access some file and fails because of the chroot().


The child process tries to exec /bin/date and fails.  The child process
then pickles the resulting exception and sends it to the parent via
a pipe that the parent has created for this purpose.  The parent then
tries to unpickle the exception and fails to find the string-escape
decoder in its usual place, due to the chroot.

If you fix that, then the parent process will be able to re-raise the
exception from the child process (which may or may not confuse you).


I woud advise to use the chroot command instead of chrooting your python
process, if that's possible for you.


You'll find you need to copy a lot of dynamic libraries and several
data files to your chroot box, before the normal commands in /bin work.

Keep in mind that the more features you copy to the chroot jail, the
easier it becomes to escape from it.

Hope this helps,

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

Re: Functions vs OOP

[Terry Reedy]

On 9/4/2011 4:13 AM, tinn...@isbd.co.uk wrote:

Ian Kelly  wrote:



Functional programming is about using functions in the *mathematical*
sense.  A mathematical function maps one value (or tuple of values) to
another value.  The mapped value never varies; if it did, it would be
a different function.  So functional programming eschews the use of
functions where the results depend on any internal or external state
beyond the values of the passed-in arguments, such as the variable
state of the object the method is being called on.


I think there may be another issue here.  If someone says "functional
programming" to me then I would generally assume that they *do* mean
"programming using functions".  While your distinction of the two may
be strictly correct I don't think it's the generally accepted meaning.


The distintion drawn by Ian *is* generally accepted in computer science. See
https://secure.wikimedia.org/wikipedia/en/wiki/Functional_programming
For instance, programming is C is imperative programming with functions 
but it generally is not 'functional programming' in the sense referred 
to by Ian and the Wikipedia article. Given that our docs are written by 
people who do understand the technical distinction, you are probably 
wrong to assume otherwise.


However, as I said to William, it is possible that our docs could be 
improved so as to not depend on all readers having prior knowledge of 
the intended meaning of 'functional programming'. As the use of Python 
has expanded, so has the variety of backgrounds of Python programmers.


--
Terry Jan Reedy

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

Re: allow line break at operators

[rantingrick]

On Sep 4, 10:22 am, ron3200  wrote:

> I think this is one of those areas where computers and people differ,
> but it may also depend on the persons native language as to what works
> better for them.

Yes but what works better for "them" is not always a better way of
doing things! People do foolish things all the time just from pure
habit. A foolish consistency is a foolish consistency my friend. I
mean, look at the folks who popped their cherry writing Basic code;
talk about dysfunctional!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Installing WebDAV server

[Thomas 'PointedEars' Lahn]

Fokke Nauta wrote:

> "Thomas 'PointedEars' Lahn"  wrote in message
> news:109595831.vcn276c...@pointedears.de...
> 
> 
> 
> If you don't have anything better to contribute, please stop answering.
> 
> Es gen�gt schon.

I should have expected as much from an address munger.

*plonk*

-- 
PointedEars

Bitte keine Kopien per E-Mail. / Please do not Cc: me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter label height to fit content

[Bart Kastermans]

rantingrick  writes:

> On Sep 3, 5:15 pm, Bart Kastermans  wrote:
>
>> Any suggestions?
>
> Yeah, have you considered using the "linespace()" method of tk.Font
> objects to calculate the height? Although i must say it "feels" as if
> your doing something you should not need to do, however i cannot be
> sure without knowing more about this GUI. Sounds a lot like trying to
> put socks on a rooster.
>
> http://infohost.nmt.edu/tcc/help/pubs/tkinter/std-attrs.html#fonts

Thx.  That function should allow for a bit of robustness.

I get bits of information over RSS, these are of varying length.  I
want to show 10 at a time, and scroll through them.  Now when I
scroll the window grows and shrinks depending on their size, I want
to right from the start make it high enough to contain even the
biggest that will have to be shown.  So the question is determining
the height parameter for the labels ahead of time.  My strategy has
been to put all in labels and then try to get the information from
the label of how high it needs to be made at a certain width.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Functions vs OOP

[William Gill]

On 9/4/2011 2:32 PM, Terry Reedy wrote:

On 9/4/2011 4:13 AM, tinn...@isbd.co.uk wrote:

Ian Kelly wrote:



Functional programming is about using functions in the *mathematical*
sense. A mathematical function maps one value (or tuple of values) to
another value. The mapped value never varies; if it did, it would be
a different function. So functional programming eschews the use of
functions where the results depend on any internal or external state
beyond the values of the passed-in arguments, such as the variable
state of the object the method is being called on.


I think there may be another issue here. If someone says "functional
programming" to me then I would generally assume that they *do* mean
"programming using functions". While your distinction of the two may
be strictly correct I don't think it's the generally accepted meaning.


The distintion drawn by Ian *is* generally accepted in computer science.
See
https://secure.wikimedia.org/wikipedia/en/wiki/Functional_programming
For instance, programming is C is imperative programming with functions
but it generally is not 'functional programming' in the sense referred
to by Ian and the Wikipedia article. Given that our docs are written by
people who do understand the technical distinction, you are probably
wrong to assume otherwise.

However, as I said to William, it is possible that our docs could be
improved so as to not depend on all readers having prior knowledge of
the intended meaning of 'functional programming'. As the use of Python
has expanded, so has the variety of backgrounds of Python programmers.

Since I am the one who opened this can of worms, and since I believe I 
have relocated the document that I misinterpreted,  I feel compelled to 
jump in here.


The source of my error is "Functional Programming HOWTO 
(/python-3.1.3-docs-html/howto/functional.html)"


Having arrived at this page indirectly (searching for and skimming other 
information regarding functions and methods) I was only half paying 
attention.  As a result I made the same mistake Chris did.


As a point of reference, I would not call myself a programmer, and any 
formal exposure was many, many years ago.  I am familiar with the 
concepts of procedural, declarative, and object-oriented programming, 
but not functional.  At least not in this context.


Having done a little more digging I now understand the difference. 
"Functional programming" is the proper terminology, and had I come 
across it from another direction, or with a more deliberate focus I 
probably wouldn't have made the initial mistake.


If you read the material with even a nominal understanding of the 
functional paradigm (functional relationships in a mathematical sense, 
not functions in the procedural sense), it is clear.  If you read it 
without consciously recognizing this difference, the material does 
nothing to alert you to the initial error.





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

[RELEASED] Python 3.2.2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
Python 3.2.2 maintenance release.

Python 3.2.2 mainly fixes `a regression `_ in the
``urllib.request`` module that prevented opening many HTTP resources correctly
with Python 3.2.1.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* a much improved ssl module with support for SSL contexts and certificate
  hostname matching
* a sysconfig module to access configuration information
* additions to the shutil module, among them archive file support
* many enhancements to configparser, among them mapping protocol support
* improvements to pdb, the Python debugger
* countless fixes regarding bytes/string issues; among them full support
  for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations

For a more extensive list of changes in 3.2, see

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2 visit:

http://www.python.org/download/releases/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk5j3d4ACgkQN9GcIYhpnLA2BACeLZ8nSdVOoxlJw4DnbM42neeA
fwAAoKTHetXsVxrEfvCWSorUhoJ083kZ
=5Wm1
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter label height to fit content

[rantingrick]

On Sep 4, 2:39 pm, Bart Kastermans  wrote:

> I get bits of information over RSS, these are of varying length.  I
> want to show 10 at a time, and scroll through them.  Now when I
> scroll the window grows and shrinks depending on their size, I want
> to right from the start make it high enough to contain even the
> biggest that will have to be shown.  So the question is determining
> the height parameter for the labels ahead of time.  My strategy has
> been to put all in labels and then try to get the information from
> the label of how high it needs to be made at a certain width.

I see. However i might opt instead for a text widget with columns of
wrapped text. You could use the textwrap.py module to help (although
you'll have to work around it's shortcomings for paragraphs and such).
In any event it's difficult to offer good advice without seeing the
code directly.


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

Re: Tkinter label height to fit content

[rantingrick]

On Sep 4, 2:39 pm, Bart Kastermans  wrote:

> Thx.  That function should allow for a bit of robustness.

Correction. The function is actually "tkFont.metrics(arg)" which takes
"linespace" as an optional argument.
-- 
http://mail.python.org/mailman/listinfo/python-list

pyOpenSSL 0.13 release

[exarkun]

Hello all,

I'm happy to announce the release of pyOpenSSL 0.13.  With this release, 
pyOpenSSL now supports OpenSSL 1.0.  Additionally, pyOpenSSL now works 
with PyPy.


Apart from those two major developments, the following interesting 
changes have been made since the last release:


 * (S)erver (N)ame (I)ndication is now supported.
 * There are now APIs with which the underlying OpenSSL version can be 
queried.

 * The peer's certificate chain for a connection can now be inspected.
 * New methods have been added to PKey and X509 objects exposing more 
OpenSSL functionality.


Release files are available on PyPI.  The latest development version and 
the issue tracker can be found on Launchpad.


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

Re: Functions vs OOP

[Steven D'Aprano]

William Gill wrote:

> The source of my error is "Functional Programming HOWTO
> (/python-3.1.3-docs-html/howto/functional.html)"

For those who don't have access to William's local file system, I expect
he's looking at this:

http://docs.python.org/release/3.1.3/howto/functional.html

or the most recent version:

http://docs.python.org/dev/howto/functional.html


[...]
> If you read the material with even a nominal understanding of the
> functional paradigm (functional relationships in a mathematical sense,
> not functions in the procedural sense), it is clear.  If you read it
> without consciously recognizing this difference, the material does
> nothing to alert you to the initial error.

What about the entire "Introduction" section, which starts with this
statement?

"This section explains the basic concept of functional programming"

If you would like to suggest improvements, please do so.




-- 
Steven

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

Re: Functions vs OOP

[William Gill]

On 9/4/2011 7:41 PM, Steven D'Aprano wrote:

William Gill wrote:


The source of my error is "Functional Programming HOWTO
(/python-3.1.3-docs-html/howto/functional.html)"


For those who don't have access to William's local file system, I expect
he's looking at this:

http://docs.python.org/release/3.1.3/howto/functional.html

or the most recent version:

http://docs.python.org/dev/howto/functional.html


I didn't expect anyone to access my file system so I trimmed the path, 
but left enough for an industrious soul like yourself to figure it out. 
 You did, so it seems I was correct, or do you think "functional.html" 
would have been sufficient? ;-)




[...]

If you read the material with even a nominal understanding of the
functional paradigm (functional relationships in a mathematical sense,
not functions in the procedural sense), it is clear.  If you read it
without consciously recognizing this difference, the material does
nothing to alert you to the initial error.


What about the entire "Introduction" section, which starts with this
statement?

"This section explains the basic concept of functional programming"


Which clears up the misunderstanding, how?  Unless the target audience 
is people who already understands "the basic concept of functional 
programming."  That seems like a circular reference.


The article is introducing a concept.  To assume any familiarity with 
that concept as a basis, is not an introduction.


As previously stated; I was already familiar with the concepts of 
procedural, declarative, and object-oriented programming, but not 
functional programming.  Nothing I read (I'll be honest; scanned) did 
anything to contradict my incorrect point of reference.



If you would like to suggest improvements, please do so.


How about a caveat stating something like "NOTE: functional as in 
mathematical functions, not to be confused with functions/procedures."



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

Re: Functions vs OOP

[Chris Angelico]

On Mon, Sep 5, 2011 at 9:41 AM, Steven D'Aprano
 wrote:
> http://docs.python.org/dev/howto/functional.html
>
> What about the entire "Introduction" section, which starts with this
> statement?
>
> "This section explains the basic concept of functional programming"
>
> If you would like to suggest improvements, please do so.

Well, it does invite you to skip that whole section :)

Since you asked, though, the copyeditor in me does want to suggest one
small tweak:

Second paragraph after the bullet list ends "Avoiding side effects
means not using data structures that get updated as a program runs;
every function’s output must only depend on its input." - I'd word it
as "must depend only on". Pretty immaterial, but the formal style
prefers correctness.

Somewhat more significant: Under "Modularity", may be of value to add
a paragraph about parallelism.

With functional code, it's easy for an interpreter to ascertain which
functions depend on each other (because one's return value is
another's input). Independent functions can be run in parallel without
affecting the result; the interpreter can therefore divide a complex
task across multiple CPUs without any work from the programmer.

Like I said, it's just "since you asked". :) The above paragraph is
hereby given out as public domain, use it (edit it, whatever) under
whatever license the Python docs require.

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

Hello, and request for help with 'dynamic grids'

[Simon Cropper]

Hi,

I am a applications developer - originally from Windows using primarily 
Visual Foxpro, although I am familiar with a variety of other xbase 
derivatives. I now use Linux / Ubuntu, and have been actively teaching 
myself Python with the view to migrate most of my applications to 
sqlite-based database.


I am looking for the ability to create dynamic grids in a window but 
can't for the life of me find how to do this.


Here is the functionality that I desire...
1. Have a dialog appear that allows me to select a database, e.g. 
sqlite3 database.
2. Select table in the database and have all the records appear in a 
grid. Fields represented as column, width and order adjustable, rows 
representing records. Each cell can be edited directly.
3. I would like to create filters on this grid based on attributes in 
the table. So if the table is a list of names, filter and show only 
those people with a particular first name. For people familiar with 
xbase languages it equivalent to browsing a table and applying a filter.
4. Once the record is identified I would like to select the record or 
hit enter to have the data sent to the keyboard buffer or put into the 
clipboard.


I have found most of these elements available. I can create dialogs, I 
can connect to a database, I can extract data from the tables using SQL 
but I can't find how to easily get these lists into a grid -- it appears 
to me you need to allocate list record 1 to grid row 1, list record 2 to 
grid row 2, etc and manage how many rows are displayed and 'page' 
through the table.


Am I missing something? I presume that you could just supply a list or 
array selected using SQL from a table and just pass this data to a grid 
and have it manage all the basics like if the window is resized the 
number of rows and columns are adjusted accordingly, buffering records, etc.


My investigations have generally found that windows/forms/data entry 
screen can be created for a specific table or view, but these are 
hard-wired during development. Is there anyway of rapidly defining the 
grid during runtime so any table can be viewed?


--
Cheers Simon

   Simon Cropper - Open Content Creator / Website Administrator

   Free and Open Source Software Workflow Guides
   
   Introduction   http://www.fossworkflowguides.com
   GIS Packages   http://gis.fossworkflowguides.com
   bash / Pythonhttp://scripting.fossworkflowguides.com
--
http://mail.python.org/mailman/listinfo/python-list

Need help with simple OOP Python question

[Kristofer Tengström]

Hi, I'm having trouble creating objects that in turn can have custom
objects as variables. The code looks like this:

-

class A:
sub = dict()
def sub_add(self, cls):
obj = cls()
self.sub[obj.id] = obj

class B(A):
id = 'inst'

base = A()
base.sub_add(B)
base.sub['inst'].sub_add(B)

print # prints a blank line
print base.sub['inst']
print base.sub['inst'].sub['inst']

--

Now, what I get from this is the following:
<__main__.B instance at 0x01FC20A8>
<__main__.B instance at 0x01FC20A8>
Why is this? What I want is for them to be two separate objects, but
it seems like they are the same one. I've tried very hard to get this
to work, but as I've been unsuccessful I would really appreciate some
comments on this. I'm sure it's something really easy that I just
haven't thought of.

Python version is 2.6.5 (I'm using Panda3D to create a 2½D game).
-- 
http://mail.python.org/mailman/listinfo/python-list