Re: pythonic way

[jack]

Sometimes, I need to alter the element as traverse a list like this 
(it's a sample):

c = range(10)
i = 0
for ele in c:
# do something
# branch:
c[i] = # value
i += 1

How to be pythonic？

 2012/11/2 0:54, Zero Piraeus :

:

On 1 November 2012 11:32, inshu chauhan  wrote:

  what is the most pythonic way to do this :

if 0 < ix < 10 and 0 < iy < 10 ???

As everyone else has said, it's perfectly pythonic once you stick the
colon on the end. You might find it more instantly readable with some
extra parentheses:

 if (0 < ix < 10) and (0 < iy < 10):
 # do something

... but that's really just down to taste.

  -[]z.


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

Organisation of python classes and their methods

[Martin Hewitson]

Dear list,

I'm relatively new to Python and have googled and googled but haven't found a 
reasonable answer to this question, so I thought I'd ask it here.

I'm beginning a large Python project which contains many packages, modules and 
classes. The organisation of those is clear to me.

Now, the classes can contain many methods (100s of data analysis methods) which 
operate on instances of the class they belong to. These methods can be long and 
complex. So if I put these methods all in the module file inside the class, the 
file will get insanely long. Reading on google, the answer is usually 
"refactor", but that really doesn't make sense here. It's just that the methods 
are many, and each method can be a long piece of code. So, is there a way to 
put these methods in their own files and have them 'included' in the class 
somehow? I read a little about mixins but all the solutions looked very hacky. 
Is there an official python way to do this? I don't like having source files 
with 100's of lines of code in, let alone 1000's.

Many thanks,

Martin

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

Re: Organisation of python classes and their methods

[Paul Rubin]

Martin Hewitson  writes:
> So, is there a way to put these methods in their own files and have
> them 'included' in the class somehow? ... Is there an official python
> way to do this? I don't like having source files with 100's of lines
> of code in, let alone 1000's.

That code sounds kind of smelly... why are there so many methods per
class?  

Python lets you inject new methods into existing classes (this is
sometimes called duck punching) but I don't recommend doing this.

A few hundred lines of code in a file is completely reasonable.  Even a
few thousand is ok.  IME it starts getting unwieldy at 3000 or so.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pythonic way

[Chris Angelico]

On Fri, Nov 2, 2012 at 6:14 PM, jack  wrote:
> Sometimes, I need to alter the element as traverse a list like this (it's a
> sample):
> c = range(10)
> i = 0
> for ele in c:
> # do something
> # branch:
> c[i] = # value
> i += 1
>
> How to be pythonic？

Check out the enumerate() function.

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

Re: Organisation of python classes and their methods

[Peter Otten]

Martin Hewitson wrote:

> Dear list,
> 
> I'm relatively new to Python and have googled and googled but haven't
> found a reasonable answer to this question, so I thought I'd ask it here.
> 
> I'm beginning a large Python project which contains many packages, modules
> and classes. The organisation of those is clear to me.
> 
> Now, the classes can contain many methods (100s of data analysis methods)
> which operate on instances of the class they belong to. These methods can
> be long and complex. So if I put these methods all in the module file
> inside the class, the file will get insanely long. Reading on google, the
> answer is usually "refactor", but that really doesn't make sense here.
> It's just that the methods are many, and each method can be a long piece
> of code. So, is there a way to put these methods in their own files and
> have them 'included' in the class somehow? I read a little about mixins
> but all the solutions looked very hacky. Is there an official python way
> to do this? I don't like having source files with 100's of lines of code
> in, let alone 1000's.

You googled, found the right answer ("refactor"), didn't like it and are now 
looking to cure the symptoms of the original problem?
Seriously, a good editor can deal with a long source file, but a class with 
hundreds of methods will bring trouble to any old brain.

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

Re: Organisation of python classes and their methods

[Martin Hewitson]

On 2, Nov, 2012, at 08:38 AM, Paul Rubin  wrote:

> Martin Hewitson  writes:
>> So, is there a way to put these methods in their own files and have
>> them 'included' in the class somehow? ... Is there an official python
>> way to do this? I don't like having source files with 100's of lines
>> of code in, let alone 1000's.
> 
> That code sounds kind of smelly... why are there so many methods per
> class?  

Simply because there are many different ways to process the data. The class 
encapsulates the data, and the user can process the data in many ways. Of 
course, one could have classes which encapsulate the algorithms, as well as the 
data, but it also seems natural to me to have algorithms as methods which are 
part of the data class, so the user operates on the data using methods of that 
class. 

> 
> Python lets you inject new methods into existing classes (this is
> sometimes called duck punching) but I don't recommend doing this.

Is there not a way just to declare the method in the class and put the actual 
implementation in another file on the python path so that it's picked up a run 
time?

> 
> A few hundred lines of code in a file is completely reasonable.  Even a
> few thousand is ok.  IME it starts getting unwieldy at 3000 or so.

In all other projects (in other languages) I've always tried to keep individual 
files short to ease maintainability and search-ability (if there is such a 
word).

Even if one takes reasonable numbers: 20 methods, each method has 20 lines of 
documentation, then we immediately have 400 lines in the file before writing a 
line of code. It would seem much more natural to me to have these methods in 
their own file, grouped nicely in sub-directories. But it seems this is not the 
python way. Sigh.


Thanks for your thoughts,

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

python-forum

[Sacha Rook]

Hi does anyone know where the python-form.org site has gone?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Organisation of python classes and their methods

[Martin Hewitson]

On 2, Nov, 2012, at 09:00 AM, Peter Otten <__pete...@web.de> wrote:

> Martin Hewitson wrote:
> 
>> Dear list,
>> 
>> I'm relatively new to Python and have googled and googled but haven't
>> found a reasonable answer to this question, so I thought I'd ask it here.
>> 
>> I'm beginning a large Python project which contains many packages, modules
>> and classes. The organisation of those is clear to me.
>> 
>> Now, the classes can contain many methods (100s of data analysis methods)
>> which operate on instances of the class they belong to. These methods can
>> be long and complex. So if I put these methods all in the module file
>> inside the class, the file will get insanely long. Reading on google, the
>> answer is usually "refactor", but that really doesn't make sense here.
>> It's just that the methods are many, and each method can be a long piece
>> of code. So, is there a way to put these methods in their own files and
>> have them 'included' in the class somehow? I read a little about mixins
>> but all the solutions looked very hacky. Is there an official python way
>> to do this? I don't like having source files with 100's of lines of code
>> in, let alone 1000's.
> 
> You googled, found the right answer ("refactor"), didn't like it and are now 
> looking to cure the symptoms of the original problem?
> Seriously, a good editor can deal with a long source file, but a class with 
> hundreds of methods will bring trouble to any old brain.

Well, here we disagree. Suppose I have a class which encapsulates time-series 
data. Below is a list of the absolute minimum methods one would have to process 
that data. That's close to 100 already before even having any specialised 
methods for dealing with the data.  Each of these methods will have maybe 20 
lines of documentation. That's 2000 lines already. And what if someone wants to 
extend that class to add their own processing methods? It would a maintenance 
nightmare for them to edit the actual class file, which they would then have to 
repeat each time a new version of the 'official' class file is released.

So maybe some rethinking of this design is needed to handle this 'limitation' 
of python. Perhaps grouping the processing algorithms into methods of 
processing classes, then pass the data objects to these methods. But somehow I 
don't like that. I have the feeling these methods would end up peppered with 
things like:

if this data type, do this
else if this data type, do this
else 

normally this would be solved by overloading methods in different data 
subclasses.

More thinking needed, clearly.

Martin



'abs'
'acos'
'asin'
'atan'
'atan2'
'average'
'cohere'
'conv'
'corr'
'cos'
'cov'
'cpsd'
'detrend'
'dft'
'diff'
'downsample'
'exp'
'export'
'fft'
'fftfilt'
'filter'
'filtfilt'
'find'
'heterodyne'
'hist'
'imag'
'integrate'
'interp'
'join'
'le'
'lincom'
'ln'
'load'
'log'
'log10'
'lscov'
'max'
'mean'
'median'
'min'
'minus'
'mode'
'mpower'
'mrdivide'
'mtimes'
'ne'
'norm'
'or'
'plot'
'plus'
'polyfit'
'power'
'psd'
'rdivide'
'real'
'resample'
'rms'
'round'
'save'
'scale'
'search'
'select'
'sin'
'smoother'
'sort'
'spectrogram'
'split'
'sqrt'
'std'
'sum'
'sumjoin'
'svd'
'tan'
'tfe'
'timeaverage'
'times'
'timeshift'
'transpose'
'uminus'
'upsample'
'zeropad'

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

Re: python-forum

[Chris Rebert]

On Fri, Nov 2, 2012 at 1:19 AM, Sacha Rook  wrote:
> Hi does anyone know where the python-form.org site has gone?

Some googling suggests that it's under new management:
http://mcompute.co.uk/showthread.php?tid=2161

But comp.lang.python/python-list is better anyway [ ;-) ], and you're
already here, so why not stay a while?

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

Re: lazy properties?

[Stefan H. Holek]

On 01.11.2012, at 22:38, Andrea Crotti wrote:

> Seeing the wonderful "lazy val" in Scala I thought that I should try to get 
> the following also in Python.
> The problem is that I often have this pattern in my code:
> 
> class Sample:
>def __init__(self):
>self._var = None
> 
>@property
>def var(self):
>if self._var is None:
>self._var = long_computation()
>else:
>return self._var
> 
> 
> which is quite useful when you have some expensive attribute to compute that 
> is not going to change.
> I was trying to generalize it in a @lazy_property but my attempts so far 
> failed, any help on how I could do that?

There is a ready made and well tested lazy decorator at 
http://pypi.python.org/pypi/lazy

Stefan

-- 
Stefan H. Holek
ste...@epy.co.at

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

Re: Organisation of python classes and their methods

[Mark Lawrence]

On 02/11/2012 08:08, Martin Hewitson wrote:


Even if one takes reasonable numbers: 20 methods, each method has 20 lines of 
documentation, then we immediately have 400 lines in the file before writing a 
line of code. It would seem much more natural to me to have these methods in 
their own file, grouped nicely in sub-directories. But it seems this is not the 
python way. Sigh.

Thanks for your thoughts,

Martin



20 lines of documentation per method?  As far as I'm concerned that's 
not a smell, that's a stink.


--
Cheers.

Mark Lawrence.

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

Re: pythonic way

[jack]

thanks,but I don't think enumerate() is my want
Have some ways to operate the reference of element,not a copy when I 
tried to traverse a list?


I'm so sorry about my poor English, hope you don't mind it.

On 2012/11/2 15:56, Chris Angelico wrote:

On Fri, Nov 2, 2012 at 6:14 PM, jack  wrote:

Sometimes, I need to alter the element as traverse a list like this (it's a
sample):
 c = range(10)
 i = 0
 for ele in c:
 # do something
 # branch:
 c[i] = # value
 i += 1

How to be pythonic？

Check out the enumerate() function.

ChrisA


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

Re: Negative array indicies and slice()

[Andrew Robinson]

Hi Ian,

I apologize for trying your patience with the badly written code 
example.  All objects were meant to be ThirdParty(), the demo was only 
to show how a slice() filter could have been applied for the reasons 
PEP357 made index() to exist.
eg: because numpy items passed to __getitems__ via slice syntax [::] 
were illegal values.
PEP 357 is the one who specifically mentioned Numpy types -- which is 
the only reason I used the name in the example;  I could have just as 
well used a string.


I am fully aware of what numpy does -- I have used it; modified the 
fortran interfaces underneath, etc.


The index() method, however, affects *all* list objects in Python, not 
just Numpy's -- correct?


I'll write a working piece of code tomorrow to demonstrate the filter 
very clearly rather than a skeleton, and test it before posting.


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

Re: Organisation of python classes and their methods

[Robert Kern]

On 11/2/12 8:20 AM, Martin Hewitson wrote:


On 2, Nov, 2012, at 09:00 AM, Peter Otten <__pete...@web.de> wrote:


Martin Hewitson wrote:


Dear list,

I'm relatively new to Python and have googled and googled but haven't
found a reasonable answer to this question, so I thought I'd ask it here.

I'm beginning a large Python project which contains many packages, modules
and classes. The organisation of those is clear to me.

Now, the classes can contain many methods (100s of data analysis methods)
which operate on instances of the class they belong to. These methods can
be long and complex. So if I put these methods all in the module file
inside the class, the file will get insanely long. Reading on google, the
answer is usually "refactor", but that really doesn't make sense here.
It's just that the methods are many, and each method can be a long piece
of code. So, is there a way to put these methods in their own files and
have them 'included' in the class somehow? I read a little about mixins
but all the solutions looked very hacky. Is there an official python way
to do this? I don't like having source files with 100's of lines of code
in, let alone 1000's.


You googled, found the right answer ("refactor"), didn't like it and are now
looking to cure the symptoms of the original problem?
Seriously, a good editor can deal with a long source file, but a class with
hundreds of methods will bring trouble to any old brain.


Well, here we disagree. Suppose I have a class which encapsulates time-series 
data. Below is a list of the absolute minimum methods one would have to process 
that data. That's close to 100 already before even having any specialised 
methods for dealing with the data.  Each of these methods will have maybe 20 
lines of documentation. That's 2000 lines already. And what if someone wants to 
extend that class to add their own processing methods? It would a maintenance 
nightmare for them to edit the actual class file, which they would then have to 
repeat each time a new version of the 'official' class file is released.


Do not make them methods of the time-series class. Make functions that take a 
time-series object. Then you can organize the functions in separate modules to 
your heart's content and import them all into a single convenience namespace.


--
Robert Kern

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

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

Re: pythonic way

[Chris Angelico]

On Fri, Nov 2, 2012 at 7:58 PM, jack  wrote:
> thanks,but I don't think enumerate() is my want
> Have some ways to operate the reference of element,not a copy when I tried
> to traverse a list?
>
> I'm so sorry about my poor English, hope you don't mind it.

No probs, I'll be a little less vague and pointer-y and give you some
example code. :)

lst = ['foo', 'bar', 'quux', 'asdf', 'qwer', 'zxcv']
for idx, val in enumerate(lst):
if val[1]=='w': lst[idx]='Replaced'
print(lst)

['foo', 'bar', 'quux', 'asdf', 'Replaced', 'zxcv']


Does that explain it a bit better? You get the index and can then
mutate the list using that index, thus replacing the original entry.

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

Re: Organisation of python classes and their methods

[Peter Otten]

Martin Hewitson wrote:

> 
> On 2, Nov, 2012, at 09:00 AM, Peter Otten <__pete...@web.de> wrote:
> 
>> Martin Hewitson wrote:
>> 
>>> Dear list,
>>> 
>>> I'm relatively new to Python and have googled and googled but haven't
>>> found a reasonable answer to this question, so I thought I'd ask it
>>> here.
>>> 
>>> I'm beginning a large Python project which contains many packages,
>>> modules and classes. The organisation of those is clear to me.
>>> 
>>> Now, the classes can contain many methods (100s of data analysis
>>> methods) which operate on instances of the class they belong to. These
>>> methods can be long and complex. So if I put these methods all in the
>>> module file inside the class, the file will get insanely long. Reading
>>> on google, the answer is usually "refactor", but that really doesn't
>>> make sense here. It's just that the methods are many, and each method
>>> can be a long piece of code. So, is there a way to put these methods in
>>> their own files and have them 'included' in the class somehow? I read a
>>> little about mixins but all the solutions looked very hacky. Is there an
>>> official python way to do this? I don't like having source files with
>>> 100's of lines of code in, let alone 1000's.
>> 
>> You googled, found the right answer ("refactor"), didn't like it and are
>> now looking to cure the symptoms of the original problem?
>> Seriously, a good editor can deal with a long source file, but a class
>> with hundreds of methods will bring trouble to any old brain.
> 
> Well, here we disagree. Suppose I have a class which encapsulates
> time-series data. Below is a list of the absolute minimum methods one
> would have to process that data. That's close to 100 already before even
> having any specialised methods for dealing with the data.  Each of these
> methods will have maybe 20 lines of documentation. That's 2000 lines
> already. And what if someone wants to extend that class to add their own
> processing methods? 

from timeseries import TimeSeries

class MyTimeSeries(TimeSeries):
def average():
# specialised implementation

> It would a maintenance nightmare for them to edit the
> actual class file, which they would then have to repeat each time a new
> version of the 'official' class file is released.

Patient: Doctor, it hurts when I ... 
Doctor: Then don't do that.

> So maybe some rethinking of this design is needed to handle this
> 'limitation' of python. Perhaps grouping the processing algorithms into
> methods of processing classes, then pass the data objects to these
> methods. But somehow I don't like that. I have the feeling these methods
> would end up peppered with things like:
> 
> if this data type, do this
> else if this data type, do this
> else 
> 
> normally this would be solved by overloading methods in different data
> subclasses.

You could ask your TimeSeries for the appropriate Statistics subclass

stats = ts.get_stats()
print stats.mean()

where get_stats() is a classmethod that returns an object that provides 
min(), max(), average() etc.
 
Another approach are mix-in classes:

class Stats:
def min(): ...
def average(): ...

class SpecialStats(Stats):
def min(): return 42

class TimeSeries(BaseTimeSeries, Stats):
pass

class SpecialTimeSeries(BaseTimeSeries, SpecialStats):
pass

> 'abs'
[...]
> 'zeropad'

You are not perchance reimplementing numpy?

> More thinking needed, clearly.

That will never hurt. Well, almost:

http://www.theonion.com/articles/beaver-overthinking-dam,1942/

:)


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

Re: Organisation of python classes and their methods

[Chris Angelico]

On Fri, Nov 2, 2012 at 7:08 PM, Martin Hewitson  wrote:
>
> On 2, Nov, 2012, at 08:38 AM, Paul Rubin  wrote:
>
>> Martin Hewitson  writes:
>>> So, is there a way to put these methods in their own files and have
>>> them 'included' in the class somehow? ... Is there an official python
>>> way to do this? I don't like having source files with 100's of lines
>>> of code in, let alone 1000's.
>>
>> That code sounds kind of smelly... why are there so many methods per
>> class?
>
> Simply because there are many different ways to process the data. The class 
> encapsulates the data, and the user can process the data in many ways. Of 
> course, one could have classes which encapsulate the algorithms, as well as 
> the data, but it also seems natural to me to have algorithms as methods which 
> are part of the data class, so the user operates on the data using methods of 
> that class.

Are these really needing to be methods, or ought they to be
module-level functions? Remember, Python code doesn't have to be
organized into classes the way Java code is.

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

Re: Obnoxious postings from Google Groups

[Jamie Paul Griffin]

/ ru...@yahoo.com wrote on Thu  1.Nov'12 at 15:08:26 -0700 /

> On 11/01/2012 03:55 AM, Jamie Paul Griffin wrote:
> > Anybody serious about programming should be using a form of
> > UNIX/Linux if you ask me. It's inconceivable that these systems
> > should be avoided if you're serious about Software Engineering and
> > Computer Science, etc. For UNIX there are loads of decent news
> > reading software and mail user agents to learn and use. slrn is a
> > good one and point it at gmane.org as someone else pointed out. I
> > can't even imagine using a browser or Google Groups, etc. now.
 
> Are you saying that this group is only for "serious" programmers?
 
I don't see where my comments suggested that this group is only for serious 
programmers. I simply believe that the UNIX platform, in whatever form, is 
better placed and designed for all sorts of computing and engineering projects. 
The history of UNIX speaks for itself. Many Universities that offer respected 
and credible science based degree programmes, namely engineering and computing 
programmes, strongly encourage students to become competent with UNIX systems. 
Windows in my opinion is really for those who use the internet on a casual 
basis or in a commercial environment where its staff are not necessarily 
computer literate and therefore need a platform that they can use which doesn't 
require them to learn more complex techniques and protocols. But, having said 
that, I'm not against Windows at all. I use it frequently and enjoy using it 
most of the time. 

> "serious" is also a matter of opinion.  I have some serious
> programmer friends who maintain, in complete sincerity, that
> serious programmers should not waste time on slow, script-kiddie
> languages like Python, but should be developing their skills 
> with serious professional languages like Java, C#, etc.

That is a narrow minded approach. different languages serve different purposes 
and it's down to the developer to use which language she needs to achieve what 
it is they've set out to do. Sometimes, basic shell scripts can be extremely 
powerful for certain tasks; other needs will require something different. I 
certainly wouldn't describe Python as a "script-kiddie" language. It's 
extremely powerful and modern. So there ;-P lol
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Organisation of python classes and their methods

[Martin Hewitson]

On 2, Nov, 2012, at 09:40 AM, Mark Lawrence  wrote:

> On 02/11/2012 08:08, Martin Hewitson wrote:
>> 
>> Even if one takes reasonable numbers: 20 methods, each method has 20 lines 
>> of documentation, then we immediately have 400 lines in the file before 
>> writing a line of code. It would seem much more natural to me to have these 
>> methods in their own file, grouped nicely in sub-directories. But it seems 
>> this is not the python way. Sigh.
>> 
>> Thanks for your thoughts,
>> 
>> Martin
>> 
> 
> 20 lines of documentation per method?  As far as I'm concerned that's not a 
> smell, that's a stink.

Wow, I don't think I've ever been criticised before for writing too much 
documentation :)

I guess we have different end users. This is not a set of classes for other 
developers to use: it's a set of classes which creates a data analysis 
environment for scientists to use. They are not programmers, and expect the 
algorithms to be documented in detail.

Martin

> 
> -- 
> Cheers.
> 
> Mark Lawrence.
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list


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

Re: datetime issue

[Jamie Paul Griffin]

/ ru...@yahoo.com wrote on Thu  1.Nov'12 at 15:00:48 -0700 /

> 
> * In Search dialog clicked on the Search in folder dropdown after
>   an earlier search and TB crashed (disappeared along with the
>   new message I was editing.) [3.0.1]
> 
> * Search for japanese text in body no longer works (never finds
>   text even when it exists). [3.0.1] Used to work.
> 
> * Each mail message displays useless header info that uses 25%
>   of the available vertical space.  
> 
> * When editing a reply message, typing a return at eol results in
>   two blank lines inserted.
> 
> * When editing message, siometimes edit cursor disappears
>   tho editing still seems to work normally.
> 
> * Requires voodoo to create hmtl new message when default is
>   plain text or visa versa.  Have to hold shift key while clicking
>   "write" button.  Shift while choosing "new", "reply", etc in
>   menu doesn't work.  
> 
> * Frequently, clinking on a usenet newsgroup results in TB freeze.
>   Only solution is to remove group and re-add later.  (Problem 
>   since 2.x days.)
> 
> * Frequently after an apparently normal shutdown, attempt to restart
>   results in "TB is already running" error.
> 
> * Some folders in the folder tree view are greyed out and not 
>   selectable even though they have no visible different properties
>   than selectable ones.  Don't know how they got that way.
> 
> * Clicking on a folder in the folder tree pane results in a pop-
>   up dialog "this folder is not selectable" that has to be dismissed,
>   even though one is trying to get it's properties, or is selecting
>   it to create a subfolder.
> 
> * Messages change from "read" to "unread" in folders at random when
>   folder is accessed, or even when it is not accessed. [gone in 3.0.3?]
> 
> * Interminttently, when I click a usenet message to view it,
>   the contents pane remains blank.  Contents of that message
>   remain blank foreever. [new with 3.0.1].
> 
> * When TB main window closed while editing an email, can no longer
>   save the email, even if the TB main window is reopened.
> 
> * Counts of new messages in usenet groups are often wildly high.
> 
> * When opening up a usenet server, status bar reports "no new
>   messages on server" even though TB then updates the groups 
>   with the new messages that *are* on the server.  [new in 3.0.1]
> 
> * After upgrade to TB-3.0, opening a usenet server results not
>   only in the group being scanned for new messages in each group
>   (as before) but also the headers for all those new messages
>   being downloaded (slow on a dialup connection and a waste of
>   time if I don't intend to read anything in that group).
>   No obvious way to revert to original behaviour.
> 
> * Even tho the number of unread messages listed beside a usenet
>   group in the folder pane is less than the download limit, I
>   sometimes get pop-up asking how many messages to download,
>   when I access the group. (side effect of above problem I think.)
> 
> * Sometimes TB downloads two copies of each header.
> 
> * When I compress folders, get a series of several dozen pop-
>   up messages (each requiring a click on "OK") telling me
>   that foplder "xx" is not selectable.
> 
> * Copy-paste from TB to other app fails if TB is closed
>   before the paste -- the paste buffer appears empty [TB-3.0b4]
> 
> * Copy paste fails by removing text (forgot if it is just the
>   copied text or other text) in the TB message when pasted
>   somewhere else. [TB-2?]
> 
> * After upgrade to TB-3.0x, i no longer see a way to create a 
>   new imap subfolder.  Had to create it using MSOE.
> 
> * After upgrade to TB-3.0x double clicking on attached .jpg image
>   no longer opens it -- only option is to save and open outside
>   of TB.  phfft.
> 
> * HTF do you change the font size for plain text message composition?
>   Prefs has a setting for html but...
> 
> * search of body for multiple "anded" text never ends if one of
>   the search boxes is empty.  
> 
> * Search "stop" button doesn't stop search.
> 
> * One group frequently, without any action on my part, read thousands 
>   of old articles, showing them as unread, and when I choose one, responds
>   with "article expired" message.  (tb-3.0.4)
 
[ ... ]

With a list of problems like that maybe the time spent on learning how to use a 
Usenet client or mua that is properly written would be worthwhile. Personally I 
haven't used the Google Groups interface, and most likely never will so I can't 
really comment on how it performs or how nice it is to use but if you're happy 
with it that's the main thing. But you can't deny that it does cause irritating 
problems for other people trying to read information sent from it. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Organisation of python classes and their methods

[Frank Millman]

On 02/11/2012 08:16, Martin Hewitson wrote:

Dear list,

I'm relatively new to Python and have googled and googled but haven't found a 
reasonable answer to this question, so I thought I'd ask it here.

I'm beginning a large Python project which contains many packages, modules and 
classes. The organisation of those is clear to me.

Now, the classes can contain many methods (100s of data analysis methods) which operate 
on instances of the class they belong to. These methods can be long and complex. So if I 
put these methods all in the module file inside the class, the file will get insanely 
long. Reading on google, the answer is usually "refactor", but that really 
doesn't make sense here. It's just that the methods are many, and each method can be a 
long piece of code. So, is there a way to put these methods in their own files and have 
them 'included' in the class somehow? I read a little about mixins but all the solutions 
looked very hacky. Is there an official python way to do this? I don't like having source 
files with 100's of lines of code in, let alone 1000's.

Many thanks,

Martin



I have read the other responses, so I may get some flak for encouraging 
bad habits. Nevertheless, I did have a similar requirement, and I found 
a solution that worked for me.


My situation was not as extreme as yours. I had a class with a number of 
methods. Some of them were of an 'operational' nature - they represented 
the main functionality of the class, and could be called often. Some of 
them were of a 'setup' nature - they were optionally called when the 
object was instantiated, but would only be called once.


I found that when I wanted to focus on one set of methods, the other set 
'got in my way', and vice-versa. My solution was to take the 'setup' 
methods and put them in another file. This is how I did it.


BEFORE
==

main.py -

class MyClass:
def setup1(self, ...):
[...]
def setup2(self, ...):
[...]
def func1(self, ...):
[...]
def func2(self, ...):
[...]


AFTER
=

setup.py -

def setup1(self, ...):
[...]
def setup2(self, ...):
[...]

main.py -

import setup
class MyClass:
setup1 = setup.setup1
setup2 = setup.setup2
def func1(self, ...):
[...]
def func2(self, ...):
[...]


Hope this gives you some ideas.

Frank Millman


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

Re: Organisation of python classes and their methods

[Peter Otten]

Martin Hewitson wrote:

> On 2, Nov, 2012, at 09:40 AM, Mark Lawrence 
> wrote:

>> 20 lines of documentation per method?  As far as I'm concerned that's not
>> a smell, that's a stink.
> 
> Wow, I don't think I've ever been criticised before for writing too much
> documentation :)
> 
> I guess we have different end users. This is not a set of classes for
> other developers to use: it's a set of classes which creates a data
> analysis environment for scientists to use. They are not programmers, and
> expect the algorithms to be documented in detail.

While I would never discourage thorough documentation you may be better off 
with smaller docstrings and the details in an external document. Python 
projects typically use rst-files processed by sphinx.

http://pypi.python.org/pypi/Sphinx/

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

Re: Organisation of python classes and their methods

[Steven D'Aprano]

On Fri, 02 Nov 2012 08:40:06 +, Mark Lawrence wrote:

> On 02/11/2012 08:08, Martin Hewitson wrote:
>>
>> Even if one takes reasonable numbers: 20 methods, each method has 20
>> lines of documentation, then we immediately have 400 lines in the file
>> before writing a line of code. It would seem much more natural to me to
>> have these methods in their own file, grouped nicely in
>> sub-directories. But it seems this is not the python way. Sigh.
>>
>> Thanks for your thoughts,
>>
>> Martin
>>
>>
> 20 lines of documentation per method?  As far as I'm concerned that's
> not a smell, that's a stink.

Depends on the method. For some, 20 lines is 18 lines too many. For 
others, that's 80 lines too few.



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

Re: Negative array indicies and slice()

[Robert Kern]

On 11/2/12 8:57 AM, Andrew Robinson wrote:

Hi Ian,

I apologize for trying your patience with the badly written code example.  All
objects were meant to be ThirdParty(), the demo was only to show how a slice()
filter could have been applied for the reasons PEP357 made index() to exist.
eg: because numpy items passed to __getitems__ via slice syntax [::] were
illegal values.
PEP 357 is the one who specifically mentioned Numpy types -- which is the only
reason I used the name in the example;  I could have just as well used a string.

I am fully aware of what numpy does -- I have used it; modified the fortran
interfaces underneath, etc.

The index() method, however, affects *all* list objects in Python, not just
Numpy's -- correct?


Please forget that PEP 357 mentions slices at all. The motivation for the 
__index__() method (not index()) goes far beyond slices. I'm not really sure why 
they are given such a prominent place in the PEP. Let me try to lay out the 
motivation more clearly.


numpy has objects that represent integers but cannot be subclasses of the Python 
int or long objects because their internal representations are different. These 
are the width-specific types: uint8, int16, int64, etc. Before __index__() was 
introduced, all indexing operations in the builtin Python sequence types 
strictly checked for int or long objects and rejected other objects. We wanted 
to provide a generic method that third party types could implement to say, "Yes, 
I really am an integer, here is my value in a canonical representation you can 
understand." We could not use __int__() for this purpose because it has 
additional semantics, namely conversion from not-integers to integers. This is 
why floats are mentioned; they do not generally represent integers but they do 
define an __int__() method for their conversion to ints via the floor() 
function. Generally, they should be rejected as indices. With the __index__() 
method, we have a solution: int16 and the rest get __index__() methods and float 
doesn't.


This is used where an integer index or offset is needed, not just in slices. 
List indices, file.seek(), mmap.mmap(), etc. The change to use PyIndex_Check() 
instead of PyInt_Check() was not very difficult or extensive. Even if you were 
to change the slicing API for your other reasons, __index__() would still be needed.


--
Robert Kern

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

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

Re: Organisation of python classes and their methods

[Mark Lawrence]

On 02/11/2012 08:45, Martin Hewitson wrote:


On 2, Nov, 2012, at 09:40 AM, Mark Lawrence  wrote:


On 02/11/2012 08:08, Martin Hewitson wrote:


Even if one takes reasonable numbers: 20 methods, each method has 20 lines of 
documentation, then we immediately have 400 lines in the file before writing a 
line of code. It would seem much more natural to me to have these methods in 
their own file, grouped nicely in sub-directories. But it seems this is not the 
python way. Sigh.

Thanks for your thoughts,

Martin



20 lines of documentation per method?  As far as I'm concerned that's not a 
smell, that's a stink.


Wow, I don't think I've ever been criticised before for writing too much 
documentation :)

I guess we have different end users. This is not a set of classes for other 
developers to use: it's a set of classes which creates a data analysis 
environment for scientists to use. They are not programmers, and expect the 
algorithms to be documented in detail.

Martin



You've completely missed the point.  99% of the time if you can't write 
down what a method does in at most half a dozen lines, the method is 
screaming out to be refactored.  Rightly or wrongly you've already 
rejected that option, although I suspect that rightly is nearer the mark 
in this case on the grounds that practicality beats purity.


--
Cheers.

Mark Lawrence.

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

word sense disambiguation

[nachiket]

hello,

do you know how to perform word sense disambiguation.

Input:- sentence
Output:- Sense tagged words.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Organisation of python classes and their methods

[Robert Kern]

On 11/2/12 10:21 AM, Peter Otten wrote:

Martin Hewitson wrote:


On 2, Nov, 2012, at 09:40 AM, Mark Lawrence 
wrote:



20 lines of documentation per method?  As far as I'm concerned that's not
a smell, that's a stink.


Wow, I don't think I've ever been criticised before for writing too much
documentation :)

I guess we have different end users. This is not a set of classes for
other developers to use: it's a set of classes which creates a data
analysis environment for scientists to use. They are not programmers, and
expect the algorithms to be documented in detail.


While I would never discourage thorough documentation you may be better off
with smaller docstrings and the details in an external document. Python
projects typically use rst-files processed by sphinx.

http://pypi.python.org/pypi/Sphinx/


In the science/math community, we tend to build the Sphinx API reference from 
the thorough, authoritative docstrings. We like having complete docstrings 
because we are frequently at the interactive prompt. We tend to have broad APIs, 
so having a single source of documentation and not repeating ourselves is important.


  http://docs.scipy.org/doc/numpy/reference/index.html
  http://docs.scipy.org/doc/scipy/reference/index.html
  http://www.sagemath.org/doc/reference/
  http://docs.sympy.org/0.7.2/modules/index.html
  http://scikit-learn.org/stable/modules/classes.html

--
Robert Kern

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

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

Re: Organisation of python classes and their methods

[Robert Kern]

On 11/2/12 10:48 AM, Mark Lawrence wrote:

On 02/11/2012 08:45, Martin Hewitson wrote:


On 2, Nov, 2012, at 09:40 AM, Mark Lawrence  wrote:


On 02/11/2012 08:08, Martin Hewitson wrote:


Even if one takes reasonable numbers: 20 methods, each method has 20 lines
of documentation, then we immediately have 400 lines in the file before
writing a line of code. It would seem much more natural to me to have these
methods in their own file, grouped nicely in sub-directories. But it seems
this is not the python way. Sigh.

Thanks for your thoughts,

Martin



20 lines of documentation per method?  As far as I'm concerned that's not a
smell, that's a stink.


Wow, I don't think I've ever been criticised before for writing too much
documentation :)

I guess we have different end users. This is not a set of classes for other
developers to use: it's a set of classes which creates a data analysis
environment for scientists to use. They are not programmers, and expect the
algorithms to be documented in detail.

Martin


You've completely missed the point.  99% of the time if you can't write down
what a method does in at most half a dozen lines, the method is screaming out to
be refactored.  Rightly or wrongly you've already rejected that option, although
I suspect that rightly is nearer the mark in this case on the grounds that
practicality beats purity.


You've completely missed the context. These are not really complicated methods 
doing lots of things all at once such that can be refactored to simpler methods. 
The docstrings are not just glorified comments for other developers reading the 
source code. They are the online documentation for non-programmer end-users who 
are using the interactive prompt as an interactive data analysis environment. 
Frequently, they not only have to describe what it's doing, but also introduce 
the whole concept of what it's doing, why you would want to do such a thing, and 
provide examples of its use. That's why they are so long. For example:


http://docs.scipy.org/doc/numpy/reference/generated/numpy.fft.fft.html

--
Robert Kern

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

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

Re: word sense disambiguation

[Robert Kern]

On 11/2/12 10:49 AM, nachiket wrote:

hello,

do you know how to perform word sense disambiguation.

Input:- sentence
Output:- Sense tagged words.


You've asked this already, and I have pointed you to NLTK.

  http://nltk.org/
  http://nltk.org/book/ch06.html
  http://nltk.org/api/nltk.classify.html

--
Robert Kern

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

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

Re: Organisation of python classes and their methods

[Ulrich Eckhardt]

Am 02.11.2012 09:08, schrieb Martin Hewitson:

On 2, Nov, 2012, at 08:38 AM, Paul Rubin 
wrote:

Martin Hewitson  writes:

So, is there a way to put these methods in their own files and
have them 'included' in the class somehow? ... Is there an
official python way to do this? I don't like having source files
with 100's of lines of code in, let alone 1000's.


That code sounds kind of smelly... why are there so many methods
per class?


Simply because there are many different ways to process the data. The
class encapsulates the data, and the user can process the data in
many ways. Of course, one could have classes which encapsulate the
algorithms, as well as the data, but it also seems natural to me to
have algorithms as methods which are part of the data class, so the
user operates on the data using methods of that class.


This is largely a matter of taste and a question of circumstances, but 
I'd like to point out here that your "natural" is not universal. If you 
take a different approach, namely that a class should encapsulate in 
order to maintain its internal consistency but otherwise be as small as 
possible, then algorithms operating on some data are definitely not part 
of that data. The advantage is that the data class gets smaller, and in 
the algorithms you don't risk ruining the internal integrity of the used 
data.


Further, encapsulating algorithms into classes is also not natural. 
Algorithms are often expressed much better as functions. Shoe-horning 
things into a class in the name of OOP is IMHO misguided.


Concerning mixins, you can put them into separate modules[1]. If it is 
clearly documented that class FooColourMixin handles the colour-related 
stuff for class Foo, and reversely that class Foo inherits FooShapeMixin 
and FooColourMixin that provide handling of shape and colour, then that 
is fine. It allows you to not only encapsulate things inside class Foo 
but to partition things inside Foo. Note that mixins are easier to write 
than in C++. If the mixin needs access to the derived class' function 
bar(), it just calls self.bar(). There is no type-casting or other magic 
involved. The same applies to data attributes (non-function attributes), 
basically all attributes are "virtual". The compile-time, static type 
checking of e.g. C++ doesn't exist.




Python lets you inject new methods into existing classes (this is
sometimes called duck punching) but I don't recommend doing this.


Is there not a way just to declare the method in the class and put
the actual implementation in another file on the python path so that
it's picked up a run time?


To answer your question, no, not directly. Neither is there a separation 
like in C++ between interface and implementation, nor is there something 
like in C# with partial classes. C++ interface/implementation separation 
is roughly provided by abstract base classes. C# partial classes are 
most closely emulated with mixins.


That said, modifying classes is neither magic nor is it uncommon:

  class foo:
  pass

  import algo_x
  foo.algo = algo_x.function

Classes are not immutable, you can add and remove things just like you 
can do with objects.



BTW: If you told us which language(s) you have a background in, it could 
be easier to help you with identifying the idioms in that language that 
turn into misconceptions when applied to Python.


Greetings!

Uli

[1] Actually, modules themselves provide the kind of separation that I 
think you are after. Don't always think "class" if it comes to 
encapsulation and modularization!

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

Re: Organisation of python classes and their methods

[Ulrich Eckhardt]

Am 02.11.2012 09:20, schrieb Martin Hewitson:

Well, here we disagree. Suppose I have a class which encapsulates
time-series data. Below is a list of the absolute minimum methods one
would have to process that data.

[...]
> 'abs' 'acos' 'asin' 'atan' 'atan2' 'average' 'cohere' 'conv' 'corr'
> 'cos' 'cov' 'cpsd' 'detrend' 'dft' 'diff' 'downsample' 'exp'
> 'export' 'fft' 'fftfilt' 'filter' 'filtfilt' 'find' 'heterodyne'
> 'hist' 'imag' 'integrate' 'interp' 'join' 'le' 'lincom' 'ln' 'load'
> 'log' 'log10' 'lscov' 'max' 'mean' 'median' 'min' 'minus' 'mode'
> 'mpower' 'mrdivide' 'mtimes' 'ne' 'norm' 'or' 'plot' 'plus'
> 'polyfit' 'power' 'psd' 'rdivide' 'real' 'resample' 'rms' 'round'
> 'save' 'scale' 'search' 'select' 'sin' 'smoother' 'sort'
> 'spectrogram' 'split' 'sqrt' 'std' 'sum' 'sumjoin' 'svd' 'tan' 'tfe'
> 'timeaverage' 'times' 'timeshift' 'transpose' 'uminus' 'upsample'
> 'zeropad'


Just as a suggestion, you can separate these into categories:

1. Things that modify the data, yielding a different (although derived) 
data set, e.g. import/load, split, join, plus, minus, zeropad.
2. Things that operate on the data without modifying it, e.g. 
export/save, average, find, plot, integrate.


The latter can easily be removed from the class. Since they don't touch 
the content, they can't invalidate internals and can't break encapsulation.


For the former, providing general means to construct or modify the data 
(like e.g. adding records or joining sequences) is also all that needs 
to remain inside the class to ensure internal consistency, everything 
else can be built on top of these using external functions.



Uli



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

Re: date and time comparison how to

[Adam Tauno Williams]

On Mon, 2012-10-29 at 16:13 -0700, noydb wrote:
> All,
> I need help with a date and time comparison.
> Say a user enters a date-n-time and a file on disk.  I want to compare
> the date and time of the file to the entered date-n-time; if the file
> is newer than the entered date-n-time, add the file to a list to
> process.
> How best to do?  I have looked at the datetime module, tried a few
> things, no luck.
> Is os.stat a part of it?  Tried, not sure of the output, the
> st_mtime/st_ctime doesnt jive with the file's correct date and
> time.  ??
> Any help would be appreciated!

Date and time is much more complicated then people guess at first.




What do you mean by "st_mtime/st_ctime doesnt jive with the file's
correct date"?  Is it off my some offset, or does it completely not
match?

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

Proper place for everything

[Jason Benjamin]

Anybody know of the appropriate place to troll and flame about various 
Python related issues?  I'm kind of mad about some Python stuff and I 
need a place to vent where people may or may not listen, but at at least 
respond.  Thought this would be a strange question, but I might as well 
start somewhere.

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

Re: Proper place for everything

[Robert Kern]

On 11/2/12 11:20 AM, Jason Benjamin wrote:

Anybody know of the appropriate place to troll and flame about various Python
related issues?  I'm kind of mad about some Python stuff and I need a place to
vent where people may or may not listen, but at at least respond.  Thought this
would be a strange question, but I might as well start somewhere.


There are plenty of good, free blog hosting options.

--
Robert Kern

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

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

Re: Proper place for everything

[Tim Golden]

On 02/11/2012 11:20, Jason Benjamin wrote:
> Anybody know of the appropriate place to troll and flame about various
> Python related issues?  I'm kind of mad about some Python stuff and I
> need a place to vent where people may or may not listen, but at at least
> respond.  Thought this would be a strange question, but I might as well
> start somewhere.

A Blog seems the obvious choice. If you don't already have one there are
certainly freely-hosted ones available: blogspot, wordpress, etc.

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

Re: Proper place for everything

[Alister]

On Fri, 02 Nov 2012 04:20:20 -0700, Jason Benjamin wrote:

> Anybody know of the appropriate place to troll and flame about various
> Python related issues?  I'm kind of mad about some Python stuff and I
> need a place to vent where people may or may not listen, but at at least
> respond.  Thought this would be a strange question, but I might as well
> start somewhere.

Trolls & flames are probably best sent to /dev/null




-- 
The meta-Turing test counts a thing as intelligent if it seeks to
devise and apply Turing tests to objects of its own creation.
-- Lew Mammel, Jr.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Proper place for everything

[Ulrich Eckhardt]

Am 02.11.2012 12:20, schrieb Jason Benjamin:

Anybody know of the appropriate place to troll and flame about various
Python related issues?  I'm kind of mad about some Python stuff and I
need a place to vent where people may or may not listen, but at at least
respond.  Thought this would be a strange question, but I might as well
start somewhere.


Depending on the kind of responses you want I would try 
alt.comp.zoo.reptiles or maybe a PHP mailinglist. Alternatively, if you 
are willing to invest some real money, I would suggest a good Islay 
single malt or a gym membership. If health, money and time are of no 
importance to you, I heard of these things called girlfriends or 
boyfriends, these could be completely overhyped rumours though.


Uli

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

Re: Proper place for everything

[Jason Benjamin]

Yeah, alright.  I've just found that if you mention anything about a 
library that has well established competitors, the post will tend to get 
ignored here.


On 11/02/2012 04:38 AM, Robert Kern wrote:

On 11/2/12 11:20 AM, Jason Benjamin wrote:

Anybody know of the appropriate place to troll and flame about various
Python
related issues?  I'm kind of mad about some Python stuff and I need a
place to
vent where people may or may not listen, but at at least respond.
Thought this
would be a strange question, but I might as well start somewhere.


There are plenty of good, free blog hosting options.



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

Re: Proper place for everything

[Zero Piraeus]

:

On 2 November 2012 07:20, Jason Benjamin  wrote:
> Anybody know of the appropriate place to troll and flame about various
> Python related issues?

I don't know about appropriate, but there'd be a certain amount of
poetic justice in using one of the alt.conspiracy.* or  alt.religion.*
newsgroups ...

 -[]z.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Obnoxious postings from Google Groups

[Grant Edwards]

On 2012-11-02, Steven D'Aprano  wrote:
> On Fri, 02 Nov 2012 10:32:08 +1100, Chris Angelico wrote:
>
>> And there are probably still a few around who maintain that Java, C#,
>> and even C are too modern, and that serious programmers use FORTRAN or
>> COBOL.
>
> Huh. If you're messing about with ancient[1] languages like Java, C# and 
> especially C, you're not a real programmer. Real programmers use modern, 
> advanced languages like D, Erlang, Go or Haskell.

Don't forget Smalltalk!  Old, but always modern and advanced...

-- 
Grant Edwards   grant.b.edwardsYow! !  Everybody out of
  at   the GENETIC POOL!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Proper place for everything

[Tim Golden]

On 02/11/2012 13:49, Jason Benjamin wrote:
> Yeah, alright.  I've just found that if you mention anything about a
> library that has well established competitors, the post will tend to get
> ignored here.

I'm not sure exactly what you're referring to. (Perhaps you can link to
an existing post or discussion).

Without hearing a tone of voice, I'm not sure whether with "... will
tend to get ignored here" you're suggesting a conspiracy of silence or
merely a general lack of interest.

The people who read and post here are the people who read and post here.
And they comment according to whatever interests them or whatever
opinions they hold. That people choose to respond to a post about
Library A and not to one about Library B should not be construed as
representing any kind of behind-the-scenes action encouraging or
suppressing interest. It simply means that the people who felt like it
commented on Library A and not on Library B.

Or have I misunderstood the tenor of your comment?

TJG

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

Re: Organisation of python classes and their methods

[Martin Hewitson]

On 2, Nov, 2012, at 11:49 AM, Ulrich Eckhardt  
wrote:

> Am 02.11.2012 09:20, schrieb Martin Hewitson:
>> Well, here we disagree. Suppose I have a class which encapsulates
>> time-series data. Below is a list of the absolute minimum methods one
>> would have to process that data.
> [...]
> > 'abs' 'acos' 'asin' 'atan' 'atan2' 'average' 'cohere' 'conv' 'corr'
> > 'cos' 'cov' 'cpsd' 'detrend' 'dft' 'diff' 'downsample' 'exp'
> > 'export' 'fft' 'fftfilt' 'filter' 'filtfilt' 'find' 'heterodyne'
> > 'hist' 'imag' 'integrate' 'interp' 'join' 'le' 'lincom' 'ln' 'load'
> > 'log' 'log10' 'lscov' 'max' 'mean' 'median' 'min' 'minus' 'mode'
> > 'mpower' 'mrdivide' 'mtimes' 'ne' 'norm' 'or' 'plot' 'plus'
> > 'polyfit' 'power' 'psd' 'rdivide' 'real' 'resample' 'rms' 'round'
> > 'save' 'scale' 'search' 'select' 'sin' 'smoother' 'sort'
> > 'spectrogram' 'split' 'sqrt' 'std' 'sum' 'sumjoin' 'svd' 'tan' 'tfe'
> > 'timeaverage' 'times' 'timeshift' 'transpose' 'uminus' 'upsample'
> > 'zeropad'
> 
> 
> Just as a suggestion, you can separate these into categories:
> 
> 1. Things that modify the data, yielding a different (although derived) data 
> set, e.g. import/load, split, join, plus, minus, zeropad.
> 2. Things that operate on the data without modifying it, e.g. export/save, 
> average, find, plot, integrate.
> 
> The latter can easily be removed from the class. Since they don't touch the 
> content, they can't invalidate internals and can't break encapsulation.
> 
> For the former, providing general means to construct or modify the data (like 
> e.g. adding records or joining sequences) is also all that needs to remain 
> inside the class to ensure internal consistency, everything else can be built 
> on top of these using external functions.
> 

Thank you all so much for your thoughts and suggestions. I need to absorb all 
of this and decide on the best approach in this case.

Thanks again,

Martin

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

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

Re: Organisation of python classes and their methods

[Martin Hewitson]

> 
> 
> BTW: If you told us which language(s) you have a background in, it could be 
> easier to help you with identifying the idioms in that language that turn 
> into misconceptions when applied to Python.

I'm considering porting some MATLAB code to python to move away from commercial 
software. Python seemed like the right choice simply because of the wonderful 
numpy, scipy and matplotlib.

So my project will build on these packages to provide some additional state and 
functionality.

Cheers,

Martin

> 
> Greetings!
> 
> Uli
> 
> [1] Actually, modules themselves provide the kind of separation that I think 
> you are after. Don't always think "class" if it comes to encapsulation and 
> modularization!
> -- 
> http://mail.python.org/mailman/listinfo/python-list

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

Re: Avoiding defunct processes

[Nobody]

On Thu, 01 Nov 2012 19:16:17 -0700, Richard wrote:

> I create child processes with subprocess.Popen().
> Then I either wait for them to finish or kill them.
> Either way these processes end up as defunct until the parent process
> completes:
> $ ps e
> 6851 pts/5Z+ 1:29 [python] 

You need to either call the .wait() method, or keep calling the .poll()
method until the .returncode attribute is not None.

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

What the diferences : web.py Tornado Twisted ?!

[nepaul]

What the diferences : web.py Tornado Twisted ?!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python-forum

[Sacha Rook]

Thanks for the update and the invite don't mind if I do.

cheers

sachlar



On 2 November 2012 08:26, Chris Rebert  wrote:

> On Fri, Nov 2, 2012 at 1:19 AM, Sacha Rook  wrote:
> > Hi does anyone know where the python-form.org site has gone?
>
> Some googling suggests that it's under new management:
> http://mcompute.co.uk/showthread.php?tid=2161
>
> But comp.lang.python/python-list is better anyway [ ;-) ], and you're
> already here, so why not stay a while?
>
> Cheers,
> Chris
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Organisation of python classes and their methods

[Mark Lawrence]

On 02/11/2012 14:49, Martin Hewitson wrote:

[Top posting fixed]






BTW: If you told us which language(s) you have a background in, it could be 
easier to help you with identifying the idioms in that language that turn into 
misconceptions when applied to Python.




Greetings!

Uli

[1] Actually, modules themselves provide the kind of separation that I think you are 
after. Don't always think "class" if it comes to encapsulation and 
modularization!
--
http://mail.python.org/mailman/listinfo/python-list


I'm considering porting some MATLAB code to python to move away from commercial 
software. Python seemed like the right choice simply because of the wonderful 
numpy, scipy and matplotlib.

So my project will build on these packages to provide some additional state and 
functionality.

Cheers,

Martin



Just in case you're not aware there are separate mailing lists for numpy 
and matplotlib, presumably scipy as well, should you have specific 
questions.  Further matplotlib is now at version 1.2rc3 with Python 3 
support, yippee.  Combine that with the recently released Python 3.3 and 
it should make one hell of a tool kit :)


--
Cheers.

Mark Lawrence.

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

Re: Organisation of python classes and their methods

[Paul Rubin]

Martin Hewitson  writes:
> Well, here we disagree. Suppose I have a class which encapsulates
> time-series data. Below is a list of the absolute minimum methods one
> would have to process that data. ... 
> 'abs'
> 'acos'
> 'asin'
> ...

Ok, THERE is your problem.  Why do you have separate implementations of
all those functions?  Does the abs of a time series simply mean the abs
of each element of the series?  In that case you want just ONE method,
something like "map", which applies an arbitrary function to all
elements of the series.  Then for time series ts, instead of saying
ts.abs(), you'd say ts.map(abs) where abs is the existing, built-in
absolute value function.  You could similarly say ts.map(acos) etc.
That gets rid of almost all of those methods.
-- 
http://mail.python.org/mailman/listinfo/python-list

csv read clean up and write out to csv

[Sacha Rook]

Hi

I have a problem with a csv file from a supplier, so they export data to csv 
however the last column in the record is a description which is marked up with 
html.

trying to automate the processing of this csv to upload elsewhere in a useable 
format. If i open the csv with csved it looks like all the records aren't 
escaped correctly as after a while i find html tags and text on the next 
line/record.

If I 'openwith' excel the description stays on the correct line/record?

I want to use python to read these records in and output a valid csv with the 
descriptions intact preferably without the html tags so a string of text 
formatted with newline/CR where appropriate.

So far I have this but don't know where to go from here can someone help me?

import csv

infile = open('c:\data\input.csv', 'rb')
outfile = open('c:\data\output.csv', 'wb')

reader = csv.reader(infile)
writer = csv.writer(outfile)


for line in reader:
print line
writer.writerow(line)


The input.csv is set out as follows;
HEADER ROW 1st
"FileDate","ProductID","Name","StandardPrice","DropshipPrice","SRP","Brand","Xline","InStock","Stock","Barcode","Weight","CategoryID","Category","SmallImage","LargeImage","Description"

A COMPLETE RECORD LOOKS LIKE THIS WITH THE DESCRIPTION FIELD POPULATED SOME 
RECORDS DON'T HAVE THE DESCRIPTION FIELD POPULATED

"2012-11-01T18:28:45.25+00:00","10198","(Venom) PS2 DVD Remote Control 
(Black)","3.7800","4.3500","12.9800","Venom","true","In 
Stock","1","5031300025009","200","1339","PC/Games_Console / Playstation / PS2 / 
Remote 
Controls","http://www.atssitecentre.co.uk/images/products/1/10198.gif","http://www.atssitecentre.co.uk/images/products/1/10198f.jpg","Never
 have to unplug your joypad / DVD user friendly / Works up to 30 feet from PS/2 
/ IR wireless technology."

THIS IS AN EXAMPLE OF THE BAD RECORD CAUSING PROBLEMS, THE DESCRIPTION FIELD 
STARTS ""features:
AS YOU CAN SEE CONTAINS HTML BUT BECAUSE OF THIS FORMAT SUBSEQUENT HTML TAGS ARE
ADDED AS NEW RECORDS ON SUBSEQUENT LINES. 

"2012-11-01T18:28:45.25+00:00","6","3.5 inch Disk Drive 
Lock","2.9500","2.9500","9.9500","None","true","In 
Stock","3","077511994166","131","1332","PC/Games_Console / PC Security / 
General","http://www.atssitecentre.co.uk/images/products/11000/6.gif","http://www.atssitecentre.co.uk/images/products/11000/6f.jpg","features:

3 1/2" FDD Lock.
Die casting housing and cylinder chrome plated.
Lock Cover : PBT + GF 15%. (PLASTIC)
2 Keys supplied per lock. 
"

I know I am far from complete but don't know how to proceed :-)
As I said I want to reconstruct a clean record either strip out the html tags 
or 
at least escape the records appropriately..

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

Re: Obnoxious postings from Google Groups

[Ian Kelly]

On Fri, Nov 2, 2012 at 3:36 AM, Jamie Paul Griffin  wrote:
> / ru...@yahoo.com wrote on Thu  1.Nov'12 at 15:08:26 -0700 /
>
>> On 11/01/2012 03:55 AM, Jamie Paul Griffin wrote:
>> > Anybody serious about programming should be using a form of
>> > UNIX/Linux if you ask me. It's inconceivable that these systems
>> > should be avoided if you're serious about Software Engineering and
>> > Computer Science, etc. For UNIX there are loads of decent news
>> > reading software and mail user agents to learn and use. slrn is a
>> > good one and point it at gmane.org as someone else pointed out. I
>> > can't even imagine using a browser or Google Groups, etc. now.
>
>> Are you saying that this group is only for "serious" programmers?
>
> I don't see where my comments suggested that this group is only for serious 
> programmers. I simply believe that the UNIX platform, in whatever form, is 
> better placed and designed for all sorts of computing and engineering 
> projects. The history of UNIX speaks for itself. Many Universities that offer 
> respected and credible science based degree programmes, namely engineering 
> and computing programmes, strongly encourage students to become competent 
> with UNIX systems. Windows in my opinion is really for those who use the 
> internet on a casual basis or in a commercial environment where its staff are 
> not necessarily computer literate and therefore need a platform that they can 
> use which doesn't require them to learn more complex techniques and 
> protocols. But, having said that, I'm not against Windows at all. I use it 
> frequently and enjoy using it most of the time.

I am comfortable with both Windows and Unix systems, and I do not find
that either environment is particularly more effective for software
engineering or helps me to be more productive than the other.  My job
has me developing Windows software, so I use Windows at work since at
the very least I require it for testing and debugging.  I could use
virtualization to run Unix as well, and I have known some who do, but
my philosophy is: why waste time dealing with two distinct
environments where only one is required?

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

Re: Organisation of python classes and their methods

[Martin Hewitson]

On 2, Nov, 2012, at 06:24 PM, Paul Rubin  wrote:

> Martin Hewitson  writes:
>> Well, here we disagree. Suppose I have a class which encapsulates
>> time-series data. Below is a list of the absolute minimum methods one
>> would have to process that data. ... 
>>   'abs'
>>   'acos'
>>   'asin'
>> ...
> 
> Ok, THERE is your problem.  Why do you have separate implementations of
> all those functions?  Does the abs of a time series simply mean the abs
> of each element of the series?  In that case you want just ONE method,
> something like "map", which applies an arbitrary function to all
> elements of the series.  Then for time series ts, instead of saying
> ts.abs(), you'd say ts.map(abs) where abs is the existing, built-in
> absolute value function.  You could similarly say ts.map(acos) etc.
> That gets rid of almost all of those methods.

Well, because one of the features that the framework will have is to capture 
history steps (in a tree structure) so that each processing step the user does 
is tracked. So while methods such as abs(), cos(), etc will eventually just 
call a built-in method, there will be some house-keeping around them. All that 
said, as I've been trying to implement this structure, it turns out that in 
Python, this is more naturally achieved (I think) if each algorithm is 
implemented as a class, so that each algorithm can return its set of supported 
parameters for validation against the user inputs and, ultimately, for 
inclusion in a step in the history tree. Since most of that infrastructure will 
turn out to be boiler-plate code, it would make sense to have an algorithm base 
class, which all other algorithms (abs, cos, etc) will inherit from. Then I 
just need to get my head around the interplay between these algorithm classes 
and the data classes. Some more prototyping needed.

Thanks for the info about map(); this will likely turn out to be very useful, 
if not at the user level, at least within the framework. Again, a main 
requirement is that the users should be able to work without knowing much about 
Python or programming in general; they just get this toolkit and, after minimal 
training should be able to do most of what they want in an intuitive way.

Cheers,

Martin



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


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

Re: How to improve the usability of nested packages

[Terry Reedy]

nested package == subpackage


or would you maybe structure the library entirely different?


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


* In my current project, I started with all modules in subpackages but 
have since moved them into the package and deleted the subpackages.


--
Terry Jan Reedy

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

Re: Proper place for everything

[Jason Benjamin]

It's a *really* old post, but it was back when I was first started 
learning Python when Python 3 wasn't out yet.  It was a dumb question so 
I can see why people wouldn't have had interest in answering it, but I 
had been developing a game and wanted to find a recommendation on a GUI 
toolkit.  Now that that's out, yes, I realize I could have searched the 
Internet for some ideas, but I tend to have tunnel vision when it comes 
to the Internet, much like modern teenagers seem to only realize they 
can communicate with Facebook.  The incident may have been isolated, but 
I stereotype.



On 11/02/2012 10:31 AM, Dennis Lee Bieber wrote:

On Fri, 02 Nov 2012 06:49:18 -0700, Jason Benjamin
 declaimed the following in
gmane.comp.python.general:


Yeah, alright.  I've just found that if you mention anything about a
library that has well established competitors, the post will tend to get
ignored here.


Interesting... The oldest post still in my news reader's cache is
October 17.

Since that time, there are only two posts under your name in that
cache, both in this thread. You should maybe provide some link to such a
post so late-comers or others can find them... a message-ID could be
useful...

I'll concede some posts may have been removed from the cache due to
filter actions (though for this group as found on gmane I only have
three active filters, and your name is not in any of them).



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

Re: How to improve the usability of nested packages

[Stefan H. Holek]

Hi Michael,

What we have learned from creating the Zope Toolkit (formerly Zope 3), is that 
__init__.py files in namespace packages should be empty, and imports should be 
absolute. [1]

That said, there are ways to avoid import cycles. One is to very carefully 
craft your modules so they do not have to import from each other. Another is to 
not have imports at the module level, but move them into the functions where 
they are required. Third, large libraries like the Zope Toolkit usually have 
mechanisms to defer imports to some point after initial loading. You may want 
explore this direction as well. [2]

(Not trying to plug the ZTK here, it just happens to be a large, 
namespace-using library I know.)

Hope this helps,
Stefan

[1] http://docs.zope.org/zopetoolkit/
[2] http://pypi.python.org/pypi/zope.deferredimport

-- 
Stefan H. Holek
ste...@epy.co.at

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

Re: Organisation of python classes and their methods

[Paul Rubin]

Martin Hewitson  writes:
>> you want just ONE method, something like "map"...
> Well, because one of the features that the framework will have is to
> capture history steps (in a tree structure) so that each processing
> step the user does is tracked. So while methods such as abs(), cos(),
> etc will eventually just call a built-in method, there will be some
> house-keeping around them. 

Make the "map" wrapper do the house-keeping.

> turns out that in Python, this is more naturally achieved (I think) if
> each algorithm is implemented as a class, so that each algorithm can
> return its set of supported parameters for validation against the user
> inputs and, ultimately, for inclusion in a step in the history
> tree. Since most of that infrastructure will turn out to be
> boiler-plate code, it would make sense to have an algorithm base
> class, which all other algorithms (abs, cos, etc) will inherit
> from. 

That sounds like over-use of classes and inheritance.  It's probably
easiest to just use a dictionary with functions in it (untested):

from collections import namedtuple
Ts_func = namedtuple('Ts_func', ['name', func, 'doc', 'validate'])

all_funcs = {}
def add_func(name, func, doc, validate):
   all_funcs[name] = Ts_func(name, func, doc, validate)

add_func('abs', abs, 'absolute value', lambda x: True)
add_func('acos', math.acos, 'arc cosine', lambda x: abs(x) <= 1)
...

You can then look up any of these entries and pass it to your map method.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Obnoxious postings from Google Groups

[rurpy]

On 11/02/2012 03:36 AM, Jamie Paul Griffin wrote:
> / ru...@yahoo.com wrote on Thu  1.Nov'12 at 15:08:26 -0700 /
> 
>> On 11/01/2012 03:55 AM, Jamie Paul Griffin wrote:
>>> Anybody serious about programming should be using a form of 
>>> UNIX/Linux if you ask me. It's inconceivable that these systems 
>>> should be avoided if you're serious about Software Engineering
>>> and Computer Science, etc. For UNIX there are loads of decent
>>> news reading software and mail user agents to learn and use. slrn
>>> is a good one and point it at gmane.org as someone else pointed
>>> out. I can't even imagine using a browser or Google Groups, etc.
>>> now.
> 
>> Are you saying that this group is only for "serious" programmers?
> 
> I don't see where my comments suggested that this group is only for
> serious programmers. I simply believe that the UNIX platform, in
> whatever form, is better placed and designed for all sorts of
> computing and engineering projects. The history of UNIX speaks for
> itself. Many Universities that offer respected and credible science
> based degree programmes, namely engineering and computing programmes,
> strongly encourage students to become competent with UNIX systems.
> Windows in my opinion is really for those who use the internet on a
> casual basis or in a commercial environment where its staff are not
> necessarily computer literate and therefore need a platform that they
> can use which doesn't require them to learn more complex techniques
> and protocols. But, having said that, I'm not against Windo ws at
> all. I use it frequently and enjoy using it most of the time.

Wow, that makes me feel like I am back in the 1990s!  
Thanks for the trip down memory lane.  :-)

>> "serious" is also a matter of opinion.  I have some serious 
>> programmer friends who maintain, in complete sincerity, that 
>> serious programmers should not waste time on slow, script-kiddie 
>> languages like Python, but should be developing their skills with
>> serious professional languages like Java, C#, etc.
> 
> That is a narrow minded approach. different languages serve different
> purposes and it's down to the developer to use which language she
> needs to achieve what it is they've set out to do. Sometimes, basic
> shell scripts can be extremely powerful for certain tasks; other
> needs will require something different. I certainly wouldn't describe
> Python as a "script-kiddie" language. It's extremely powerful and
> modern. So there ;-P lol

Right.  I happen to agree with you and was just repeating
an elitist attitude I've often heard where what *I* use 
is for *serious* business and what *they* use is just 
for playing around, for those without as much technical 
competence as me, etc.

Without a quantitative definition of "serious" and some
objective evidence supporting it, your opinion that unix
is more "serious" than windows is as narrow-minded as my
friends' opinion (which was the point I was trying to 
make and which you seem to have missed.)

I don't particularly like Windows and am able to mostly 
avoid it these days, but think you should realize that 
describing it as not for *serious* use is going irritate 
some people and make you look like you are not able to 
make objective judgements.  

(I also hope I haven't just been suckered by a troll
attempt, windows/unix is better then unix/windows being 
an age-old means of trolling.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: datetime issue

[rurpy]

On 11/02/2012 03:57 AM, Jamie Paul Griffin wrote:
> / ru...@yahoo.com wrote on Thu  1.Nov'12 at 15:00:48 -0700 /
>> [...list of Thunderbird problems...]
>
> With a list of problems like that maybe the time spent on learning
> how to use a Usenet client or mua that is properly written would be
> worthwhile.

And that would be which one exactly?  I have tried a few 
other mail and usenet clients, and as I said, indeed the 
point of my post was, they *all* have their own set of 
bugs, misfeatures and missing features.

> Personally I haven't used the Google Groups interface,
> and most likely never will so I can't really comment on how it
> performs or how nice it is to use but if you're happy with it that's
> the main thing. But you can't deny that it does cause irritating
> problems for other people trying to read information sent from it.

I can and do deny that.  I certainly acknowledge that 
GG contributes to such posts, but naive users of GG and 
readers who are too easily irritated are two other major 
contributing factors.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Proper place for everything

[Jason Benjamin]

On another note, it appears that Google (the only archive I can find for 
this group) only has a little under 400 messages archived for this 
group, while the slackware newsgroup has upwards 40,000 and contains 
posts I can't even remember that were made with one of the first emails 
I've ever used.


On 11/02/2012 10:31 AM, Dennis Lee Bieber wrote:

On Fri, 02 Nov 2012 06:49:18 -0700, Jason Benjamin
 declaimed the following in
gmane.comp.python.general:


Yeah, alright.  I've just found that if you mention anything about a
library that has well established competitors, the post will tend to get
ignored here.


Interesting... The oldest post still in my news reader's cache is
October 17.

Since that time, there are only two posts under your name in that
cache, both in this thread. You should maybe provide some link to such a
post so late-comers or others can find them... a message-ID could be
useful...

I'll concede some posts may have been removed from the cache due to
filter actions (though for this group as found on gmane I only have
three active filters, and your name is not in any of them).



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

Haskell -> Python

[foster63]

Hi All,

As part of a Nim solver I'm playing around with I'm trying to code this Haskell 
snippet:

  options [x] = zero : [ [y] | y <- [1..x - 1] ]
  options (x:xs) = map (++ xs) (options [x]) ++ map (x:) (options xs)

in Python.  So far I have this, which works OK, but somehow doesn't feel right:

def options( heaps ):

if heaps == []: return []

head, tail = heaps[:1], heaps[1:]

# Calculate all possible moves which is the sum of 
# prepending all possible head "moves" to the tail 
# and appending all possible tail "moves" to the head

return [ [h] + tail for h in range( head[0] ) ] \
 + [ head + t   for t in options( tail )  ]

Is there anything anyone could recommend to make it more "Pythonic" or more 
functional.  It looks clumsy next to the Haskell.

Regards

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

Re: csv read clean up and write out to csv

[Neil Cerutti]

On 2012-11-02, Sacha Rook  wrote:
> Hi
>
> I have a problem with a csv file from a supplier, so they
> export data to csv however the last column in the record is a
> description which is marked up with html.
>
> trying to automate the processing of this csv to upload
> elsewhere in a useable format. If i open the csv with csved it
> looks like all the records aren't escaped correctly as after a
> while i find html tags and text on the next line/record.

Maybe compose a simple parter to disambiguate the lines from the
file.

Something like (you'll have to write is_html, and my Python 2 is
mighty rusty, you'll have to fix up. Note that infile doesn't
have to be in binary mode with this scheme, but it would fail on
bizarre newlines in the file):

def parse_records(iter):
for line in iter:
if is_html(line):
yield ('html', line)
else:
yield ('csv', csv.reader([line.strip()]).next())

infile = open('c:\data\input.csv')
outfile = open('c:\data\output.csv', 'wb')

writer = csv.writer(outfile)

for tag, rec in parse_record(infile):
if tag == 'html':
print rec
elif tag == 'csv':
writer.writerow(rec)
else:
raise ValueError("Unknown record type %s" % tag)

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

Re: csv read clean up and write out to csv

[Hans Mulder]

On 2/11/12 18:25:09, Sacha Rook wrote:
> I have a problem with a csv file from a supplier, so they export data to csv
> however the last column in the record is a description which is marked up
> with html.
> 
> trying to automate the processing of this csv to upload elsewhere in a
> useable format. If i open the csv with csved it looks like all the records
> aren't escaped correctly as after a while i find html tags and text on the
> next line/record.

The example line you gave was correctly escaped: the description starts
with a double quote, and ends several lines later with another double
quote.  Double quotes in the HTML are represented by '"'.

Maybe csved doesn't recognize this escape convention?

> If I 'openwith' excel the description stays on the correct line/record?

Excel implements this convention

> I want to use python to read these records in and output a valid csv with
> the descriptions intact preferably without the html tags so a string of
> text formatted with newline/CR where appropriate.

How about this:

import csv

infile = file("input.csv", "rb")
outfile = file("output.csv", "wb")

reader = csv.reader(infile)
writer = csv.writer(outfile)

for line in reader:
line[-1] = line[-1].replace("\n", " ")
print line
writer.writerow(line)

infile.close()
outfile.close()


That will replace the newlines inside the HTML, which your csved
doesn't seem to recognize, by spaces.  When viewed as HTML code,
spaces have the same effect as newlines, so this replacement
shouldn't alter the meaning of the HTML text.

Hope this helps,

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

Re: Haskell -> Python

[Dave Angel]

On 11/02/2012 03:19 PM, foste...@gmail.com wrote:
> Hi All,
>
> As part of a Nim solver I'm playing around with I'm trying to code this 
> Haskell snippet:
>
>   options [x] = zero : [ [y] | y <- [1..x - 1] ]
>   options (x:xs) = map (++ xs) (options [x]) ++ map (x:) (options xs)
>
> in Python.  So far I have this, which works OK, but somehow doesn't feel 
> right:
>
> def options( heaps ):
>
> if heaps == []: return []
> 
> head, tail = heaps[:1], heaps[1:]
> 
> # Calculate all possible moves which is the sum of 
> # prepending all possible head "moves" to the tail 
> # and appending all possible tail "moves" to the head
> 
> return [ [h] + tail for h in range( head[0] ) ] \
>  + [ head + t   for t in options( tail )  ]
>
> Is there anything anyone could recommend to make it more "Pythonic" or more 
> functional.  It looks clumsy next to the Haskell.
>
> Regards
>
> etc.

You'd save people a lot of time if you'd specify that the parameter
heaps is a list of ints, perhaps initially [1,3,5,7]   or [3, 4, 5]
depending on which variation of Nim you're trying to.  There are many. 
One variant is that some versions of Nim say the winner is the player
who does NOT take the last piece.  I'll assume that the goal is to end
up with [0,0,0,0]

My main problem with studying your code is that brute force is totally
unnecessary;  there's a fairly simple strategy for winning at Nim. 
Certainly it's simple enough to have perfect strategy without any computer.

A "good" move is any one where the xor of all the items in the list ends
up as zero.  There is always at least one move for an "ungood" position
that results in a "good" one.  Thus the strategy is to go from good to
good, with the opponent always stuck on an ungood one.


-- 

DaveA

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

Memory profiling: Python 3.2

[Andrew Robinson]

When Python3.2 is running, is there an easy way within Python to capture 
the *total* amount of heap space the program is actually using  (eg:real 
memory)?  And how much of that heap space is allocated to variables ( 
including re-capturable data not yet GC'd ) ?




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

Re: Proper place for everything

[Tim Golden]

On 02/11/2012 18:51, Jason Benjamin wrote:

On another note, it appears that Google (the only archive I can find for
this group) only has a little under 400 messages archived for this
group


  http://mail.python.org/pipermail/python-list/


http://markmail.org/search/?q=python#query:python%20list%3Aorg.python.python-list+page:1+state:facets

and doubtless others.

TJG

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

Re: Haskell -> Python

[Simon Foster]

On 02/11/12 19:56, Dave Angel wrote:

On 11/02/2012 03:19 PM, foste...@gmail.com wrote:

Hi All,

As part of a Nim solver I'm playing around with I'm trying to code this Haskell 
snippet:

   options [x] = zero : [ [y] | y <- [1..x - 1] ]
   options (x:xs) = map (++ xs) (options [x]) ++ map (x:) (options xs)

in Python.  So far I have this, which works OK, but somehow doesn't feel right:

def options( heaps ):

 if heaps == []: return []

 head, tail = heaps[:1], heaps[1:]

 # Calculate all possible moves which is the sum of
 # prepending all possible head "moves" to the tail
 # and appending all possible tail "moves" to the head

 return [ [h] + tail for h in range( head[0] ) ] \
  + [ head + t   for t in options( tail )  ]

Is there anything anyone could recommend to make it more "Pythonic" or more 
functional.  It looks clumsy next to the Haskell.

Regards

etc.


You'd save people a lot of time if you'd specify that the parameter
heaps is a list of ints, perhaps initially [1,3,5,7]   or [3, 4, 5]
depending on which variation of Nim you're trying to.  There are many.
One variant is that some versions of Nim say the winner is the player
who does NOT take the last piece.  I'll assume that the goal is to end
up with [0,0,0,0]

My main problem with studying your code is that brute force is totally
unnecessary;  there's a fairly simple strategy for winning at Nim.
Certainly it's simple enough to have perfect strategy without any computer.

A "good" move is any one where the xor of all the items in the list ends
up as zero.  There is always at least one move for an "ungood" position
that results in a "good" one.  Thus the strategy is to go from good to
good, with the opponent always stuck on an ungood one.




Hi Dave,

Thanks for the comments.  Yes, I should have specified that the input is 
a list of ints giving the size of each heap, and the return value should 
be a list of all game positions reachable from the input position.


At the moment I'm not concentrating on any particular Nim flavour, just 
trying to enumerate all possible moves from a given position.


I know that there's an easier way to determine winning-losing positions, 
but my question was more about programming style than Nim strategy.


My code to calculate the "nim-value" looks like this:

def nim_val( heaps ):
return functools.reduce( operator.xor, heaps, 0 )

Assuming that we're playing "non-misere" Nim then a zero nim-value is a 
lose for the player *about* to play.


Regards

Simon


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

ping in bluetooth

[Luca Sanna]

hi,
how do I send a ping in bluetooth? 
because android phones are not always visible. 
I can not find the ping command 
thanks 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Proper place for everything

[Jason Benjamin]

Yeah, now that I take a look at the said old post on this group, I can 
see why the post was ignored:


http://markmail.org/thread/mnxpzt4jzx3zjeio

On 11/02/2012 01:05 PM, Tim Golden wrote:

On 02/11/2012 18:51, Jason Benjamin wrote:

On another note, it appears that Google (the only archive I can find for
this group) only has a little under 400 messages archived for this
group


   http://mail.python.org/pipermail/python-list/


http://markmail.org/search/?q=python#query:python%20list%3Aorg.python.python-list+page:1+state:facets


and doubtless others.

TJG



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

Re: How to generate account number?

[Jose Figueroa]

Hello Andriy

Thanks for your work!

I will try it!
Jose


On Fri, Nov 2, 2012 at 3:13 PM, Andriy Kornatskyy <
andriy.kornats...@live.com> wrote:

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

Re: Haskell -> Python

[Ian Kelly]

On Fri, Nov 2, 2012 at 1:19 PM,   wrote:
> Is there anything anyone could recommend to make it more "Pythonic" or more 
> functional.  It looks clumsy next to the Haskell.

def options(heaps):
for i, heap in enumerate(heaps):
head = heaps[:i]
tail = heaps[i+1:]
yield from (head + [x] + tail for x in range(heap))

"yield from" is Python 3.3 syntax.  If you're not using Python 3.3,
then that line could be replaced by:

for x in range(heap):
yield head + [x] + tail

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

Re: Haskell -> Python

[Ian Kelly]

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

In fact, the more that I look at it, the more that I think the latter
might be preferable in any case.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Memory profiling: Python 3.2

[Antoine Pitrou]

Andrew Robinson  r3dsolutions.com> writes:
> 
> When Python3.2 is running, is there an easy way within Python to capture 
> the *total* amount of heap space the program is actually using  (eg:real 
> memory)?

I'm not sure what you mean with "real memory" or how precise you want that 
measurement to be, but you could try http://www.selenic.com/smem/
(and, within Python, re-use smem's concepts, which shouldn't be too difficult)

> And how much of that heap space is allocated to variables ( 
> including re-capturable data not yet GC'd ) ?

Again, not sure what you mean with "allocated to variables" (global variables? 
local variables? everything?). As for "re-capturable data not yet GC'd", the
best way to figure out is to run gc.collect() :-)

Regards

Antoine.


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

Re: Proper place for everything

[Steven D'Aprano]

On Fri, 02 Nov 2012 04:20:20 -0700, Jason Benjamin wrote:

> Anybody know of the appropriate place to troll and flame about various
> Python related issues?  I'm kind of mad about some Python stuff and I
> need a place to vent where people may or may not listen, but at at least
> respond.  Thought this would be a strange question, but I might as well
> start somewhere.

Thank you for your honesty, but trolling is not welcome.

However if you have actual issues about Python, either pro or con, and 
hope to have a serious, respectful dialog where both parties listen to 
each other, feel free to raise them here. Keep in mind three things:

- We've probably heard all your arguments a thousand times before. It's
  unlikely that you are either the first or the last person to notice
  that (e.g.) Python has significant indentation. So expect a certain
  amount of brusqueness.

- If your argument boils down to "Python isn't "
  we will not be sympathetic, and will probably sneer or laugh at you
  privately. And possibly publicly too.

- If you hope to convince the Python community to change ,
  we are constrained by backwards-compatibility issues, policies, and
  design decisions. Frequently there are (mis-)features that we simply
  have to live with, for good or ill.


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

Re: Proper place for everything

[Steven D'Aprano]

On Fri, 02 Nov 2012 11:51:29 -0700, Jason Benjamin wrote:

> On another note, it appears that Google (the only archive I can find for
> this group) only has a little under 400 messages archived for this
> group,

Google Groups is poison. If you post with it, you will be ignored by a 
large percentage of the regulars here.

Good options are:

- Use the official email mailing list instead of news:

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

  Do yourself (and us) a HUGE favour and use regular mail, not daily
  digests.

- If you prefer Usenet, and your ISP gives you access to comp.lang.python,
  use that.

- If not, there are many cheap Usenet providers you can try.

- Try http://news.gmane.org/gmane.comp.python.general


Bad options are:

- Absolutely anything to do with Google Groups. It's a crap user-
  interface, posts don't follow established standards for email and news,
  and Google requires you to sign in just to read the archives, which in
  my opinion is morally indefensible.



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

Re: Proper place for everything

[Steven D'Aprano]

On Fri, 02 Nov 2012 13:48:27 -0700, Jason Benjamin wrote:

> Yeah, now that I take a look at the said old post on this group, I can
> see why the post was ignored:
> 
> http://markmail.org/thread/mnxpzt4jzx3zjeio

Good lord man, that was FOUR AND A HALF YEARS AGO. Have you been holding 
a grudge for all that time? Maybe nobody knew the answer. I certainly 
don't.

The question was:

[quote]
I have some PNGs with transparent backgrounds.  How do I draw them
using PyGTK?
[end quote]


It is perfectly appropriate to wait three or four days, then reply with a 
comment requesting attention. You probably would have got some answers, 
even if they were only "take it to a specialist PyGTK mailing list".


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

Re: How to generate account number?

[GangGreene]

On Sat, 03 Nov 2012 00:13:19 +0300, Andriy Kornatskyy wrote:

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

generate sha1sum on the ((key database record(s))+date+timeofday)
Should be unique for billions/trillions of records.
-- 
http://mail.python.org/mailman/listinfo/python-list

enabling universal newline

[Peter Kleiweg]

In Python 3.1 and 3.2

At start-up, the value of sys.stdin.newlines is None, which 
means, universal newline should be enabled. But it isn't.

So I do this:

sys.stdin = io.TextIOWrapper(sys.stdin.detach(), newline=None)

Now, sys.stdin.newlines is still None, but universal newline is 
enabled.

Why is this?



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

Re: Haskell -> Python

[Dave Angel]

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



-- 

DaveA

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

Re: Haskell -> Python

[Ian Kelly]

On Fri, Nov 2, 2012 at 4:24 PM, Dave Angel  wrote:
> Perhaps range(heap) should be replaced by  range(len(heap))

"heaps" is a list of ints per the OP, so "heap" is an int.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to generate account number?

[Steven D'Aprano]

On Sat, 03 Nov 2012 00:13:19 +0300, Andriy Kornatskyy wrote:

> Requirements for `account number` generator:
> 
> 1. Issue pseudo random consistent number (must be unique for dozen
> millions of records) 

How much randomness do you need? From the perspective of any one user, a 
simple incrementing counter returns arbitrary values, which may be "close 
enough" to random.

last_num = 103872  # Pick an arbitrary starting value.
def get_account_number():
"""Return the next account number."""
global last_num
last_num += 1
return last_num

Stick that value in a database instead of a global, and you're done.

What are the consequences of people guessing account numbers? If the 
consequences are serious, then you need to make account numbers 
cryptographically strong. If the account number alone is not important, 
then you don't.


> 2. Easy check validity (without a need to make a database call)

Add a check digit to the number you generate. There are all sorts of ways 
to do that. Here are two examples:

http://code.activestate.com/recipes/577692
http://code.activestate.com/recipes/577691


> Interested? Read more here:

If you ask a question here, please keep the discussion here, don't split 
it to your personal blog.

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


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

Re: enabling universal newline

[Steven D'Aprano]

On Fri, 02 Nov 2012 23:22:53 +0100, Peter Kleiweg wrote:

> In Python 3.1 and 3.2
> 
> At start-up, the value of sys.stdin.newlines is None, which means,
> universal newline should be enabled. But it isn't.

What makes you think it is not enabled?

sys.stdin.newlines shows you the newlines actually seen. Until you put 
text including newlines through stdin, it will remain None.

http://docs.python.org/2/library/stdtypes.html#file.newlines
http://docs.python.org/3/library/io.html#io.TextIOBase.newlines

For example, I have Python built with universal newlines, but 
stdin.newlines remains None:

py> f = open('test.txt')
py> f.newlines
py> f.readlines()
['a\n', 'b\n', 'c\n', 'd\n']
py> f.newlines
('\r', '\n', '\r\n')
py> sys.stdin.newlines is None
True



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

Re: Obnoxious postings from Google Groups

[Mark Lawrence]

On 02/11/2012 18:39, ru...@yahoo.com wrote:

On 11/02/2012 03:36 AM, Jamie Paul Griffin wrote:

/ ru...@yahoo.com wrote on Thu  1.Nov'12 at 15:08:26 -0700 /


On 11/01/2012 03:55 AM, Jamie Paul Griffin wrote:

Anybody serious about programming should be using a form of
UNIX/Linux if you ask me. It's inconceivable that these systems
should be avoided if you're serious about Software Engineering
and Computer Science, etc. For UNIX there are loads of decent
news reading software and mail user agents to learn and use. slrn
is a good one and point it at gmane.org as someone else pointed
out. I can't even imagine using a browser or Google Groups, etc.
now.



Are you saying that this group is only for "serious" programmers?


I don't see where my comments suggested that this group is only for
serious programmers. I simply believe that the UNIX platform, in
whatever form, is better placed and designed for all sorts of
computing and engineering projects. The history of UNIX speaks for
itself. Many Universities that offer respected and credible science
based degree programmes, namely engineering and computing programmes,
strongly encourage students to become competent with UNIX systems.
Windows in my opinion is really for those who use the internet on a
casual basis or in a commercial environment where its staff are not
necessarily computer literate and therefore need a platform that they
can use which doesn't require them to learn more complex techniques
and protocols. But, having said that, I'm not against Windo ws at
all. I use it frequently and enjoy using it most of the time.


Wow, that makes me feel like I am back in the 1990s!
Thanks for the trip down memory lane.  :-)


"serious" is also a matter of opinion.  I have some serious
programmer friends who maintain, in complete sincerity, that
serious programmers should not waste time on slow, script-kiddie
languages like Python, but should be developing their skills with
serious professional languages like Java, C#, etc.


That is a narrow minded approach. different languages serve different
purposes and it's down to the developer to use which language she
needs to achieve what it is they've set out to do. Sometimes, basic
shell scripts can be extremely powerful for certain tasks; other
needs will require something different. I certainly wouldn't describe
Python as a "script-kiddie" language. It's extremely powerful and
modern. So there ;-P lol


Right.  I happen to agree with you and was just repeating
an elitist attitude I've often heard where what *I* use
is for *serious* business and what *they* use is just
for playing around, for those without as much technical
competence as me, etc.

Without a quantitative definition of "serious" and some
objective evidence supporting it, your opinion that unix
is more "serious" than windows is as narrow-minded as my
friends' opinion (which was the point I was trying to
make and which you seem to have missed.)

I don't particularly like Windows and am able to mostly
avoid it these days, but think you should realize that
describing it as not for *serious* use is going irritate
some people and make you look like you are not able to
make objective judgements.

(I also hope I haven't just been suckered by a troll
attempt, windows/unix is better then unix/windows being
an age-old means of trolling.)



Does Unix now have clustering, or is it still behind VMS aka Very Much 
Safer?


--
Cheers.

Mark Lawrence.

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

PDFBuilder can create composite PDFs

[vasudevram]

PDFBuilder is a tool to create composite PDFs, i.e. PDFs comprising of data 
from multiple different input data formats (any number of files, in any order). 
It is a new component of my xtopdf toolkit for PDF generation.

A blog post about PDFBuilder gives more information, an example, and a download 
link:

http://jugad2.blogspot.in/2012/11/pdfbuilderpy-can-create-composite-pdfs.html

- Vasudev Ram

http://www.dancingbison.com
http://jugad2.blogspot.com
http://twitter.com/vasudevram

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

Re: What the diferences : web.py Tornado Twisted ?!

[Mark Lawrence]

On 02/11/2012 15:50, nepaul wrote:

What the diferences : web.py Tornado Twisted ?!



Web.py is spelt w e b . p y.  Tornado is spelt T o r n a d o.  Twisted 
is spelt T w i s t e d.


--
Cheers.

Mark Lawrence.

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

Re: Organisation of python classes and their methods

[Steven D'Aprano]

On Fri, 02 Nov 2012 07:16:09 +0100, Martin Hewitson wrote:

> I'm beginning a large Python project which contains many packages,
> modules and classes. The organisation of those is clear to me.
[...]
> I don't like having source files with
> 100's of lines of code in, let alone 1000's.

Why? Do you do your software development on an iPhone?

Hundreds of lines is nothing, especially if you are including docstrings 
and comments in that count. My Python startup file is over 100 lines, and 
it is trivial.

100 lines is approximately and a half pages using a 10pt font size 
(depending on the font and the platform, of course). In any case, it's 
not a lot. If you average two lines of code every comment, blank line or 
docstring, 100 lines is only 66 lines of actual code.

To give you an example of what I consider pushing the limit of how much 
code should go into a single file, look at the source code to decimal.py. 
In Python 3.2, that file is 6249 lines. There are:

- 2880 lines of actual code
- 2070 lines in docstrings, including blanks
- 606 commented lines
- 693 blank lines outside of docstrings

The module includes 20 top-level functions, 18 classes, and 213 methods. 
Most of those methods are in just two classes, Context and Decimal, with 
76 and 117 methods respectively. So there is an average of 12 lines of 
code per function or method.

I wouldn't like to have to deal with a single file twice that size, but 
decimal.py is relatively easy to deal with. It's not a trivial module by 
any means, but nor is it especially over-complex. The complexity is all 
in the computations, not the code layout.

Please understand me -- I'm not saying that you should stuff all your 
code into a single module. Code should only be placed into a single 
module when the code is related. But in my opinion, you should not split 
a logical single unit of code, a module of related code, into separate 
files just because it is "too big" until it is at least as large as 
decimal.py.


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

Re: Organisation of python classes and their methods

[Steven D'Aprano]

On Sat, 03 Nov 2012 01:06:45 +, Steven D'Aprano wrote:

> 100 lines is approximately and a half pages using a 10pt font size
> (depending on the font and the platform, of course).

Crap. I meant approx *one* and a half pages.



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

Re: Organisation of python classes and their methods

[Steven D'Aprano]

On Fri, 02 Nov 2012 09:08:07 +0100, Martin Hewitson wrote:

> Even if one takes reasonable numbers: 20 methods, each method has 20
> lines of documentation, then we immediately have 400 lines in the file
> before writing a line of code. It would seem much more natural to me to
> have these methods in their own file, grouped nicely in sub-directories.

Ewww. Ewww ewww ewww ewww. Just reading about it makes me feel dirty.

Seriously. That means any time you want to jump back and forth from one 
method to another method OF THE SAME CLASS, you have to change files. 
Yuck.

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

Re: Haskell -> Python

[Dave Angel]

On 11/02/2012 06:27 PM, Ian Kelly wrote:
> On Fri, Nov 2, 2012 at 4:24 PM, Dave Angel  wrote:
>> Perhaps range(heap) should be replaced by  range(len(heap))
> "heaps" is a list of ints per the OP, so "heap" is an int.

You're right of course .  I was distracted by the fact that a
heap is normally a collection of thing, and didn't notice that here it
is a count of those things.

-- 

DaveA

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

Re: What the diferences : web.py Tornado Twisted ?!

[Chris Angelico]

On Sat, Nov 3, 2012 at 12:04 PM, Mark Lawrence  wrote:
> On 02/11/2012 15:50, nepaul wrote:
>>
>> What the diferences : web.py Tornado Twisted ?!
>>
>
> Web.py is spelt w e b . p y.  Tornado is spelt T o r n a d o.  Twisted is
> spelt T w i s t e d.

Wow! That's profound! Oh, the insights made available, free of charge,
by the generous members of this list!

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