Re: Image Upload with FalconFramework

[Mark Lawrence]

On 03/07/2014 04:54, Peter Romfeld wrote:

Hi,

I am stuck at a simple image upload function, in django i just used:

for feature phones:
file = request.body

iOS with Form:
class ImageForm(forms.Form):
 image = forms.FileField()


What is forms?  image is defined at the class level, not the instance 
level, did you actually mean that?



form = ImageForm(request.POST, request.FILES)
file = request.FILES['image'].read()


file has been overwritten.



with falcon i tried but not working;
req.stream.read()


req is undefined here.



Cheers,
Peter



So please give us your OS and Python versions, the exact code that 
you've tried to run, how you've tried to run it, what you expected to 
happen and what actually happened including the complete traceback if any.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: TypeError expected in an augmented assignment

[candide]

>  >>> seq = [1,2]
> 
>  >>> seq.extend((3,4))


OK, this feature is referenced in the Python Library reference here : 

https://docs.python.org/3.2/library/stdtypes.html#typesseq-mutable

not thoroughly referenced but, anyway, referenced.





> 
>  >>> seq+= {5, 6}  # the order of extending is not determined
> 
>  >>> seq
> 
> [1, 2, 3, 4, 5, 6]
> 
>  >>>

Good and interesting observation. But I can't find out where this feature is 
referenced in the Language/Library Reference. Because, as my first post 
explains, augmented assignment performs the binary operation associated to the 
augmented assignment, cf. 

https://docs.python.org/3.2/reference/simple_stmts.html#augmented-assignment-statements

so seq+= {5, 6} performs seq + {5, 6}, the later raising a TypeError.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Success with subprocess communicate on Windows?

[Wolfgang Maier]

On 07/03/2014 06:09 AM, Terry Reedy wrote:


Yes, but what puzzled me is that running
subprocess.check_output(r'pyflakes c:\programs\python34\lib')
in the regular interpreter *does* produce output instead of the error
message. My guess is that it fills up the pipe, so that check_output
starts reading the pipe long before pyflakes exits with status 1.

Hmm. I tried it again, and I see some but not all of the output I got at
the command line *and* I see the exit status message. So the subprocess
must get some of the output but then stop when it sees the exit status.
  Thanks.



For a partial explanation try this:

from the command line (again my path is slightly different):

pyflakes C:\Python34\lib > stdout.txt

this will still give you a few lines of output and these should be the 
same ones you're seeing from the python interpreter when you're doing:


subprocess.check_output(r'pyflakes C:\Python34\lib')

==> pyflakes sends these lines to stderr instead of stdout !!

confirmation:

subprocess.check_output(r'pyflakes C:\Python34\lib', stderr=subprocess.PIPE)

and the output is gone.

So the remaining questions are:
- why on earth is pyflakes sending these lines (and only these) to stderr ?

- what is happening to the stderr output when run in IDLE ? I guess it 
is caught and suppressed somewhere, but to add to your observations the 
check_output call doesn't hang on IDLE, but finishes eventually with no 
output other than the traceback.


Best wishes,
Wolfgang

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

Re: TypeError expected in an augmented assignment

[Chris Angelico]

On Thu, Jul 3, 2014 at 5:51 PM, candide  wrote:
> Good and interesting observation. But I can't find out where this feature is 
> referenced in the Language/Library Reference. Because, as my first post 
> explains, augmented assignment performs the binary operation associated to 
> the augmented assignment, cf.
>
> https://docs.python.org/3.2/reference/simple_stmts.html#augmented-assignment-statements
>
> so seq+= {5, 6} performs seq + {5, 6}, the later raising a TypeError.

>From that link:

"""
An augmented assignment expression like x += 1 can be rewritten as x =
x + 1 to achieve a similar, but not exactly equal effect. In the
augmented version, x is only evaluated once. Also, when possible, the
actual operation is performed in-place, meaning that rather than
creating a new object and assigning that to the target, the old object
is modified instead.
"""

The significance here is that the augmented assignment may not
necessarily be at all comparable to the non-augmented version, but
ought to have *approximately* the same *intention*. There are plenty
of situations where the two will differ, eg when there are multiple
references to the same object:

>>> a = b = [1,2]
>>> a += [3]
>>> a,b
([1, 2, 3], [1, 2, 3])
>>> a = a + [4]
>>> a,b
([1, 2, 3, 4], [1, 2, 3])

In its simplest form, x += 1 <-> x = x + 1, but there are plenty of
ways to distinguish them.

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

OT: speeds (physical, not computing) [was Re: 1-0.95]

[Steven D'Aprano]

On Wed, 02 Jul 2014 21:06:52 -0700, Rustom Mody wrote:

> On Thursday, July 3, 2014 7:49:30 AM UTC+5:30, Steven D'Aprano wrote:
>> On Wed, 02 Jul 2014 23:00:15 +0300, Marko Rauhamaa wrote:
> 
>> > On the other hand, floating-point numbers are perfect whenever you
>> > deal with science and measurement.
> 
>> /head-desk
> 
> 
> 
> Just as there are even some esteemed members of this list who think that
> c - a is a meaningful operation
>   where
> c is speed of light
> a is speed of an automobile
> 
> 
> 


You seem to be having some sort of nervous tic.

Subtracting two numbers a and c *is* a meaningful operation, even if they 
are speeds, and even in special relativity.

Consider an observer O in an inertial frame of reference. A car x is 
driving towards the observer at v metres per second, while a photon p 
travels away from the observer at c m/s:


x --> v  O p --> c


According to the observer, the difference in speeds between x and p is 
just (c - v), the same as in classic mechanics. The technical term for it 
is "closing speed" (or "opening speed" as the case may be) as seen by O.

Note that this is *not* the difference in speeds as observed by x, but I 
never said it was.


You don't have to believe me. You can believe the Physics FAQs, 
maintained by John Baez:

http://math.ucr.edu/home/baez/physics/Relativity/SR/velocity.html


The important part is the paragraph titled "How can that be right?" and 
ending "In this sense velocities add according to ordinary vector 
addition."

As I wanted to confirm my understanding of the situation:

https://groups.google.com/forum/#!topic/sci.physics/BqT0p_7tHYg




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

Re: Success with subprocess communicate on Windows?

[Wolfgang Maier]

On 07/03/2014 10:03 AM, Wolfgang Maier wrote:

On 07/03/2014 06:09 AM, Terry Reedy wrote:

- what is happening to the stderr output when run in IDLE ? I guess it
is caught and suppressed somewhere, but to add to your observations the
check_output call doesn't hang on IDLE, but finishes eventually with no
output other than the traceback.


stderr output not being displayed in IDLE is mentioned in 
http://bugs.python.org/issue13582 .


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

Re: general module auditing

[Rita]

On Thu, Jul 3, 2014 at 2:54 AM, Mark Lawrence 
wrote:

> On 03/07/2014 02:17, Rita wrote:
>
>>
>> On Wed, Jul 2, 2014 at 2:46 PM, Irmen de Jong > > wrote:
>>
>> On 2-7-2014 4:04, Rita wrote:
>>  > yes, this helps. But I want to know who uses the module, serpent.
>> So, when
>>  > I upgrade it or remove it they won't be affected adversely.
>>
>> (Please don't top-post, it makes the discussion harder to follow.)
>>
>>  > On Tue, Jul 1, 2014 at 2:16 PM, Irmen de Jong
>> mailto:irmen.nos...@xs4all.nl>>
>>
>>  > wrote:
>>  >
>>  >> On 1-7-2014 12:38, Rita wrote:
>>  >>> i work in a group of developers (15 or so)  who are located
>> globally. I
>>  >>> would like to know what modules everyone is uses if I ever have
>> to
>>  >> upgrade
>>  >>> my python. Is there mechanism which will let me see who is
>> using what?
>>  >>>
>>  >>> ie,
>>  >>>
>>  >>> tom,matplotlib
>>  >>> bob, pylab
>>  >>> nancy, numpy
>>  >>> nancy, matplotlib
>>  >>>
>>  >>> etc...
>>  >>>
>>  >>>
>>  >>
>>  >> Well, if your group is all using Pip (and perhaps even
>> virtualenv), you
>>  >> could use pip
>>  >> list. In my case:
>>  >>
>>  >> $ pip list
>>
>> [...]
>>
>>
>> Why would the fact that you upgrade or remove a package, affect
>> another developer in
>> your group? Are you all using the same machine to develop on, with
>> one Python installation?
>>
>> I think you'll have to tell us some more details about the way you
>> work together before
>> we can give a meaningful answer to your question.
>>
>> Irmen
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>> we have a shared mount point which has our python install. we have 3
>> servers on one part of the campus  and 2 in another part.
>>
>> I want to find out what packages our user base is using thats the final
>> goal. I can figure out who is using python by writing a wrapper but not
>> what module.
>>
>> --
>> --- Get your facts first, then you can distort them as you please.--
>>
>>
> You can check every users's program for import statements but do you
> really need to, why not check what's in the site-packages folder for your
> python install?
>
> --
> My fellow Pythonistas, ask not what our language can do for you, ask what
> you can do for our language.
>
> Mark Lawrence
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


how can i get frequency of the module usage? thats the end goal.

-- 
--- Get your facts first, then you can distort them as you please.--
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: TypeError expected in an augmented assignment

[candide]

> >From that link:
> 
> 
> 
> """
> 
> An augmented assignment expression like x += 1 can be rewritten as x =
> 
> x + 1 to achieve a similar, but not exactly equal effect. In the
> 
> augmented version, x is only evaluated once. Also, when possible, the
> 
> actual operation is performed in-place, meaning that rather than
> 
> creating a new object and assigning that to the target, the old object
> 
> is modified instead.
> 
> """
> 
> 
> 
> The significance here is that the augmented assignment may not
> 
> necessarily be at all comparable to the non-augmented version, but
> 
> ought to have *approximately* the same *intention*. 


This is not my reading. 




> 
> of situations where the two will differ, eg when there are multiple
> 
> references to the same object:
> 
> 
> 
> >>> a = b = [1,2]
> 
> >>> a += [3]
> 
> >>> a,b
> 
> ([1, 2, 3], [1, 2, 3])
> 
> >>> a = a + [4]
> 
> >>> a,b
> 
> ([1, 2, 3, 4], [1, 2, 3])
> 
> 

OK but this behavior is in conformance with the Reference Manual (cf. your 
quote above : "when possible, the actual operation is performed in-place"). 
This is not my point because the doc explictly claims that "an augmented 
assignment [...] performs the binary operation specific to the type of 
assignment on the two operands".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 1-0.95

[Steven D'Aprano]

On Thu, 03 Jul 2014 09:51:35 +0300, Marko Rauhamaa wrote:

> Steven D'Aprano :
[...]
>> By the way, there's no need to use an invented example. Here is an
>> actual example:
>>
>> py> import math
>> py> from fractions import Fraction
>> py> math.sqrt(Fraction(2))**2
>> 2.0004
> 
> Sure, although you were invoking "arbitrary-precision" rational numbers,
> which Fraction() is not.

In what way is Fraction not an arbitrary precision rational number? It's 
a rational number, and it can store numbers to any arbitrary precision 
you like (up to the limit of RAM) in any base you like. 

How about the smallest non-zero number representable in base 17 to 13004 
significant figures? I can represent that as a Fraction with no 
difficulty at all:

py> x = 1/(Fraction(17)**13004)
py> str(x)[:20] + "..." + str(x)[-5:]
'1/572497511269282241...23521'


And it is calculated *exactly*.


Now, I admit that I have misgivings about using the term "precision" when 
it comes to discussing rational numbers, since the idea of significant 
figures doesn't really work very well with fraction notation. It's not 
clear to me how many "significant figures" x above should be described as 
having. The number of digits in its decimal expansion perhaps? But you 
started using the term, not me, so I'm just following your lead.

If you don't think Fraction counts as "arbitrary precision rational 
number", what do you think does?



[...]
>> Floating-point is *hard*, not "perfect".
> 
> It can be both. 

"Perfect" requires that it be flawless. It certainly is not flawless. As 
I have repeatedly stated, there are mathematical properties which 
floating point numbers do not obey. Given that they are supposed to model 
real numbers, the fact that they do not obey the mathematical laws 
applicable to real numbers is a pretty big flaw.


> The point is, regular floating point numbers will likely
> the optimal choice for your numeric calculation needs. They are compact,
> fast and readily supported by hardware and numeric software. Switching
> to Decimal might give you a false sense of security.

Ah, now this is a much more reasonable thing to say. Why didn't you say 
so in the first place? :-)




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

threading.Condition.wait() is not catching SIGTERM

[Sangeeth Saravanaraj]

Hi All, 

I have the following code which when executed waits to be interrupted by 
SIGINT, SIGTERM or SIGQUIT. When an object is initialized, it creates a 
threading.Condition() and acquires() it! The program then registers the signal 
handlers where notify() and release() is called when the above mentioned 
signals are received. After registering the signal handlers, it calls wait() on 
the condition variable and block.

When I tried to stop the program with Ctrl-C, its did not respond. IOW, the 
_signal_handler() method did not get called.  

# start

from signal import signal, SIGINT, SIGTERM, SIGQUIT
from threading import Condition

class A:
def __init__(self):
self._termination_signal = Condition()
self._termination_signal.acquire(blocking=0)

def _signal_handler(self, signum, frame):
print "Received terminate request - signal = {0}".format(signum)
del frame
self._termination_signal.notify()
self._termination_signal.release()
return

def register_and_wait(self):
signal(SIGINT, self._signal_handler)
signal(SIGTERM, self._signal_handler)
signal(SIGQUIT, self._signal_handler)
print "Waiting to be interrupted!"
self._termination_signal.wait()  # control blocks here!
print "Notified!!"

def main():
a = A()
a.register_and_wait()

if __name__ == "__main__":
main()

# end

What am I doing wrong?! 

Thank you,

Sangeeth-- 
https://mail.python.org/mailman/listinfo/python-list

Re: threading.Condition.wait() is not catching SIGTERM

[Roy Smith]

In article ,
 Sangeeth Saravanaraj  wrote:

> Hi All, 
> 
> I have the following code which when executed waits to be interrupted by 
> SIGINT, SIGTERM or SIGQUIT.

We need more information.  What version of Python are you using?  And, 
what operating system is this running on?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: threading.Condition.wait() is not catching SIGTERM

[Sangeeth Saravanaraj]

On 03-Jul-2014, at 3:49 pm, Roy Smith  wrote:

> In article ,
> Sangeeth Saravanaraj  wrote:
> 
>> Hi All, 
>> 
>> I have the following code which when executed waits to be interrupted by 
>> SIGINT, SIGTERM or SIGQUIT.
> 
> We need more information.  What version of Python are you using?  And, 
> what operating system is this running on?

I am using Python 2.7.7 and running this code on MacOS Darwin Kernel 13.2.0

But does the behavior of threading.Condition.wait() depends on operating 
system?! 

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

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

Re: threading.Condition.wait() is not catching SIGTERM

[Chris Angelico]

On Thu, Jul 3, 2014 at 8:27 PM, Sangeeth Saravanaraj
 wrote:
> But does the behavior of threading.Condition.wait() depends on operating 
> system?!

The behaviour of signals certainly does - there's a huge difference
between Windows and POSIX, and there are lesser differences between
Linux and Mac OS, and so on. It's just safest to say exactly what
platform, in case it matters.

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

Re: 1-0.95

[Marko Rauhamaa]

Steven D'Aprano :

> If you don't think Fraction counts as "arbitrary precision rational 
> number", what do you think does?

I was assuming you were referring to an idealized datatype.

Fraction() doesn't have a square root method. Let's make one:

   def newton(x, n):
   guess = Fraction(1)
   for i in range(n):
   guess = (guess + x / guess) / 2
   return guess

   >>> newton(Fraction(2), 3)
   Fraction(577, 408)
   >>> newton(Fraction(2), 8)
   Fraction(489266466344238819545868088398566945584921822586685371455477\
   00898547222910968507268117381704646657,
   345963636159190997653185453890148615173898600719883426481871047662465\
   65694525469768325292176831232)
   >>> newton(Fraction(2), 18)

   ... keeps going and going and going ...

Point being, if you have trouble with floats, you will likely have it
with Decimal(), Fraction(), super-duper Rational(), Algebraic(),
Expressible(), you name it. You'll just have to develop an understanding
of numeric computation.

BTW, the same thing applies to integers, also. While Python has
abstracted out many of the 2's-complement arithmetic details, the bits
shine through.

>> The point is, regular floating point numbers will likely the optimal
>> choice for your numeric calculation needs. They are compact, fast and
>> readily supported by hardware and numeric software. Switching to
>> Decimal might give you a false sense of security.
>
> Ah, now this is a much more reasonable thing to say. Why didn't you
> say so in the first place? :-)

That's all I've been saying all along.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: general module auditing

[Mark Lawrence]

On 03/07/2014 10:27, Rita wrote:




On Thu, Jul 3, 2014 at 2:54 AM, Mark Lawrence mailto:breamore...@yahoo.co.uk>> wrote:

On 03/07/2014 02:17, Rita wrote:


On Wed, Jul 2, 2014 at 2:46 PM, Irmen de Jong
mailto:irmen.nos...@xs4all.nl>
__>> wrote:

 On 2-7-2014 4:04, Rita wrote:
  > yes, this helps. But I want to know who uses the module,
serpent.
 So, when
  > I upgrade it or remove it they won't be affected adversely.

 (Please don't top-post, it makes the discussion harder to
follow.)

  > On Tue, Jul 1, 2014 at 2:16 PM, Irmen de Jong
 mailto:irmen.nos...@xs4all.nl>
__>>

  > wrote:
  >
  >> On 1-7-2014 12:38, Rita wrote:
  >>> i work in a group of developers (15 or so)  who are
located
 globally. I
  >>> would like to know what modules everyone is uses if I
ever have to
  >> upgrade
  >>> my python. Is there mechanism which will let me see who is
 using what?
  >>>
  >>> ie,
  >>>
  >>> tom,matplotlib
  >>> bob, pylab
  >>> nancy, numpy
  >>> nancy, matplotlib
  >>>
  >>> etc...
  >>>
  >>>
  >>
  >> Well, if your group is all using Pip (and perhaps even
 virtualenv), you
  >> could use pip
  >> list. In my case:
  >>
  >> $ pip list

 [...]


 Why would the fact that you upgrade or remove a package, affect
 another developer in
 your group? Are you all using the same machine to develop
on, with
 one Python installation?

 I think you'll have to tell us some more details about the
way you
 work together before
 we can give a meaningful answer to your question.

 Irmen

 --
https://mail.python.org/__mailman/listinfo/python-list


we have a shared mount point which has our python install. we have 3
servers on one part of the campus  and 2 in another part.

I want to find out what packages our user base is using thats
the final
goal. I can figure out who is using python by writing a wrapper
but not
what module.

--
--- Get your facts first, then you can distort them as you please.--


You can check every users's program for import statements but do you
really need to, why not check what's in the site-packages folder for
your python install?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

how can i get frequency of the module usage? thats the end goal.

--
--- Get your facts first, then you can distort them as you please.--




Count the number of imports or count the times a given program gets run 
for the number of imports depending on what you mean.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: TypeError expected in an augmented assignment

[Mark Lawrence]

On 03/07/2014 10:35, candide wrote:




>From that link:



"""

An augmented assignment expression like x += 1 can be rewritten as x =

x + 1 to achieve a similar, but not exactly equal effect. In the

augmented version, x is only evaluated once. Also, when possible, the

actual operation is performed in-place, meaning that rather than

creating a new object and assigning that to the target, the old object

is modified instead.

"""



The significance here is that the augmented assignment may not

necessarily be at all comparable to the non-augmented version, but

ought to have *approximately* the same *intention*.



This is not my reading.






of situations where the two will differ, eg when there are multiple

references to the same object:




a = b = [1,2]



a += [3]



a,b


([1, 2, 3], [1, 2, 3])


a = a + [4]



a,b


([1, 2, 3, 4], [1, 2, 3])




OK but this behavior is in conformance with the Reference Manual (cf. your quote above : "when 
possible, the actual operation is performed in-place"). This is not my point because the doc 
explictly claims that "an augmented assignment [...] performs the binary operation specific to 
the type of assignment on the two operands".



To get the wording changed to satisfy yourself, either raise an issue on 
the bug tracker at bugs.python.org and attach a patch file, or send an 
email with suggested wording to d...@python.org.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: OOP with MyTime

[kjakupak]

On Wednesday, July 2, 2014 4:02:00 PM UTC-4, MRAB wrote:
> >
> 
> If you want 'between' to be an instance method of the MyTime class, it
> 
> needs 'self' as well as the 2 arguments 't1' and 't2'.
> 
> 
> 
> You can then compare the hours, minutes and seconds of self against
> 
> those of t1 and t2:
> 
> 
> 
>  def between(self, t1, t2):
> 
>  return (t1.hours, t1.minutes, t1.seconds) <= (self.hours, 
> 
> self.minutes, self.seconds) and (self.hours, self.minutes, self.seconds) 
> 
> <= (t2.hours, t2.minutes, t2.seconds)
> 
> 
> 
> That could be shortened further using chained comparisons.
> 
> 
> 
> Note that the code assumes that the times t1 and t2 are ordered, i.e.
> 
> that time t1 is not later/greater than time t2.

So I've now gotten this:
class MyTime:

def __init__(self, hrs=0, mins=0, secs=0):
self.hours = hrs
self.minutes = mins
self.seconds = secs

if self.seconds >= 60:
self.minutes += self.seconds // 60
self.seconds = self.seconds % 60

if self.minutes >= 60:
self.hours += self.minutes // 60
self.minutes = self.minutes % 60

if self.hours >= 24:
self.hours = self.hours % 24

def get_sec(self):
return (self.hours * 60 + self.minutes) * 60 + self.seconds

def __str__(self):
return "{:02d}:{:02d}:{:02d}".\
   format(self.hours, self.minutes, self.seconds)

def between(self, t1, t2):
return (t1.hours, t1.minutes, t1.seconds) <= (self.hours, self.minutes, 
self.seconds) and (self.hours, self.minutes, self.seconds) <= (t2.hours, 
t2.minutes, t2.seconds)


t1 = MyTime(9, 59, 59)
print("t1 =", t1)

t2 = MyTime(10, 0, 1)
print("t2 =", t2)

t3 = MyTime(10, 0, 0)
print("t3 =", t3)

print("between(t2, t3, t1) =", between(t2, t3, t1))
print("between(t1, t3, t2) =", between(t1, t3, t2))
print("between(t3, t1, t2) =", between(t3, t1, t2))
print("between(t1, t2, t3) =", between(t1, t2, t3))

Am I on the right track or? Not sure where to go from here
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OOP with MyTime

[Chris Angelico]

On Thu, Jul 3, 2014 at 10:51 PM,   wrote:
> So I've now gotten this:
> class MyTime:
> def between(self, t1, t2):
> return (t1.hours, t1.minutes, t1.seconds) <= (self.hours, 
> self.minutes, self.seconds) and (self.hours, self.minutes, self.seconds) <= 
> (t2.hours, t2.minutes, t2.seconds)
> print("between(t2, t3, t1) =", between(t2, t3, t1))

And what happens when you run this code? A NameError, I would expect.
Do you understand how to define and call methods?

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

Re: OOP with MyTime

[kjakupak]

On Thursday, July 3, 2014 9:01:09 AM UTC-4, Chris Angelico wrote:
> 
> 
> 
> And what happens when you run this code? A NameError, I would expect.
> 
> Do you understand how to define and call methods?
> 
> 
> 
> ChrisA

Altered the code. But yes a nameerror came up

class MyTime:

def __init__(self, hrs=0, mins=0, secs=0):
self.hours = hrs
self.minutes = mins
self.seconds = secs

if self.seconds >= 60:
self.minutes += self.seconds // 60
self.seconds = self.seconds % 60

if self.minutes >= 60:
self.hours += self.minutes // 60
self.minutes = self.minutes % 60

if self.hours >= 24:
self.hours = self.hours % 24

def get_sec(self):
return (self.hours * 60 + self.minutes) * 60 + self.seconds

def __str__(self):
return "{:02d}:{:02d}:{:02d}".\
   format(self.hours, self.minutes, self.seconds)

def between(self, t1, t2):
return (t1.get_sec() <= (self.get_sec()) and (self.get_sec()) <= 
(t2.get_sec())

s = MyTime()
t1 = s(9, 59, 59)
print("t1 =", t1)

t2 = s(10, 0, 1)
print("t2 =", t2)

t3 = s(10, 0, 0)
print("t3 =", t3)

print("between(t2, t3, t1) =", s.between(t2, t3, t1))
print("between(t1, t3, t2) =", s.between(t1, t3, t2))
print("between(t3, t1, t2) =", s.between(t3, t1, t2))
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OOP with MyTime

[MRAB]

On 2014-07-03 13:51, kjaku...@gmail.com wrote:

On Wednesday, July 2, 2014 4:02:00 PM UTC-4, MRAB wrote:

>

If you want 'between' to be an instance method of the MyTime class, it

needs 'self' as well as the 2 arguments 't1' and 't2'.



You can then compare the hours, minutes and seconds of self against

those of t1 and t2:



 def between(self, t1, t2):

 return (t1.hours, t1.minutes, t1.seconds) <= (self.hours,

self.minutes, self.seconds) and (self.hours, self.minutes, self.seconds)

<= (t2.hours, t2.minutes, t2.seconds)



That could be shortened further using chained comparisons.



Note that the code assumes that the times t1 and t2 are ordered, i.e.

that time t1 is not later/greater than time t2.


So I've now gotten this:
class MyTime:

 def __init__(self, hrs=0, mins=0, secs=0):
 self.hours = hrs
 self.minutes = mins
 self.seconds = secs

 if self.seconds >= 60:
 self.minutes += self.seconds // 60
 self.seconds = self.seconds % 60

 if self.minutes >= 60:
 self.hours += self.minutes // 60
 self.minutes = self.minutes % 60

 if self.hours >= 24:
 self.hours = self.hours % 24

 def get_sec(self):
 return (self.hours * 60 + self.minutes) * 60 + self.seconds

 def __str__(self):
 return "{:02d}:{:02d}:{:02d}".\
format(self.hours, self.minutes, self.seconds)

 def between(self, t1, t2):
 return (t1.hours, t1.minutes, t1.seconds) <= (self.hours, self.minutes, 
self.seconds) and (self.hours, self.minutes, self.seconds) <= (t2.hours, 
t2.minutes, t2.seconds)


t1 = MyTime(9, 59, 59)
print("t1 =", t1)

t2 = MyTime(10, 0, 1)
print("t2 =", t2)

t3 = MyTime(10, 0, 0)
print("t3 =", t3)

print("between(t2, t3, t1) =", between(t2, t3, t1))
print("between(t1, t3, t2) =", between(t1, t3, t2))
print("between(t3, t1, t2) =", between(t3, t1, t2))
print("between(t1, t2, t3) =", between(t1, t2, t3))

Am I on the right track or? Not sure where to go from here


You need to decide whether you want 'between' to be a method of the
MyTime class or a separate function.

In the above code it's defined as a method, so you can say:

t2.between(t3, t1)

which means "is t2 between t3 and t1?".

That would return False because t3 is greater than t1, but:

t2.between(t1, t3)

would return True.

(I _did_ say that it assumes that the times are ordered.)

BTW, gmail is messing up your messages. This will tell you how to fix
it:

https://wiki.python.org/moin/GoogleGroupsPython

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

Re: OOP with MyTime

[Chris Angelico]

On Thu, Jul 3, 2014 at 11:08 PM,   wrote:
> Altered the code. But yes a nameerror came up

When that sort of thing happens, you have three basic approaches to
solving the problem.

1) Read the traceback, look at the line of code it points to, and see
if you can figure out what it means.
2) Post here with the full traceback so we have a chance of being able
to help you
3) Play 20 questions with us, while making the gathering of
information as hard as pulling teeth.

Suggestion: The third option is the least effective. :)

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

Re: OOP with MyTime

[kjakupak]

On Thursday, July 3, 2014 9:11:49 AM UTC-4, MRAB wrote:
> On 2014-07-03 13:51, kjaku...@gmail.com wrote:
> 
> > On Wednesday, July 2, 2014 4:02:00 PM UTC-4, MRAB wrote:
> 
> >> >
> 
> >>
> 
> >> If you want 'between' to be an instance method of the MyTime class, it
> 
> >>
> 
> >> needs 'self' as well as the 2 arguments 't1' and 't2'.
> 
> >>
> 
> >>
> 
> >>
> 
> >> You can then compare the hours, minutes and seconds of self against
> 
> >>
> 
> >> those of t1 and t2:
> 
> >>
> 
> >>
> 
> >>
> 
> >>  def between(self, t1, t2):
> 
> >>
> 
> >>  return (t1.hours, t1.minutes, t1.seconds) <= (self.hours,
> 
> >>
> 
> >> self.minutes, self.seconds) and (self.hours, self.minutes, self.seconds)
> 
> >>
> 
> >> <= (t2.hours, t2.minutes, t2.seconds)
> 
> >>
> 
> >>
> 
> >>
> 
> >> That could be shortened further using chained comparisons.
> 
> >>
> 
> >>
> 
> >>
> 
> >> Note that the code assumes that the times t1 and t2 are ordered, i.e.
> 
> >>
> 
> >> that time t1 is not later/greater than time t2.
> 
> >
> 
> > So I've now gotten this:
> 
> > class MyTime:
> 
> >
> 
> >  def __init__(self, hrs=0, mins=0, secs=0):
> 
> >  self.hours = hrs
> 
> >  self.minutes = mins
> 
> >  self.seconds = secs
> 
> >
> 
> >  if self.seconds >= 60:
> 
> >  self.minutes += self.seconds // 60
> 
> >  self.seconds = self.seconds % 60
> 
> >
> 
> >  if self.minutes >= 60:
> 
> >  self.hours += self.minutes // 60
> 
> >  self.minutes = self.minutes % 60
> 
> >
> 
> >  if self.hours >= 24:
> 
> >  self.hours = self.hours % 24
> 
> >
> 
> >  def get_sec(self):
> 
> >  return (self.hours * 60 + self.minutes) * 60 + self.seconds
> 
> >
> 
> >  def __str__(self):
> 
> >  return "{:02d}:{:02d}:{:02d}".\
> 
> > format(self.hours, self.minutes, self.seconds)
> 
> >
> 
> >  def between(self, t1, t2):
> 
> >  return (t1.hours, t1.minutes, t1.seconds) <= (self.hours, 
> > self.minutes, self.seconds) and (self.hours, self.minutes, self.seconds) <= 
> > (t2.hours, t2.minutes, t2.seconds)
> 
> >
> 
> >
> 
> > t1 = MyTime(9, 59, 59)
> 
> > print("t1 =", t1)
> 
> >
> 
> > t2 = MyTime(10, 0, 1)
> 
> > print("t2 =", t2)
> 
> >
> 
> > t3 = MyTime(10, 0, 0)
> 
> > print("t3 =", t3)
> 
> >
> 
> > print("between(t2, t3, t1) =", between(t2, t3, t1))
> 
> > print("between(t1, t3, t2) =", between(t1, t3, t2))
> 
> > print("between(t3, t1, t2) =", between(t3, t1, t2))
> 
> > print("between(t1, t2, t3) =", between(t1, t2, t3))
> 
> >
> 
> > Am I on the right track or? Not sure where to go from here
> 
> >
> 
> You need to decide whether you want 'between' to be a method of the
> 
> MyTime class or a separate function.
> 
> 
> 
> In the above code it's defined as a method, so you can say:
> 
> 
> 
>  t2.between(t3, t1)
> 
> 
> 
> which means "is t2 between t3 and t1?".
> 
> 
> 
> That would return False because t3 is greater than t1, but:
> 
> 
> 
>  t2.between(t1, t3)
> 
> 
> 
> would return True.
> 
> 
> 
> (I _did_ say that it assumes that the times are ordered.)
> 
> 
> 
> BTW, gmail is messing up your messages. This will tell you how to fix
> 
> it:
> 
> 
> 
> https://wiki.python.org/moin/GoogleGroupsPython

I keep getting an invalid syntax on the t1 = (9, 59, 59) line, not sure why?

t1 = (9, 59, 59)
print("t1 =", t1)

t2 = (10, 0, 1)
print("t2 =", t2)

t3 = (10, 0, 0)
print("t3 =", t3)

print("between(t2, t3, t1) =", t2.between(t3, t1))
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OOP with MyTime

[Chris Angelico]

On Fri, Jul 4, 2014 at 1:21 AM,   wrote:
> I keep getting an invalid syntax on the t1 = (9, 59, 59) line, not sure why?
>
> t1 = (9, 59, 59)

Two points. Firstly, as I said before, posting the entire exception
helps us enormously. Secondly, with most computerized parsers, the
file is processed top-down, left-to-right, so it's possible for a
syntax error to be discovered a bit after where it actually happens -
but not before. So when you get parsing errors, check the immediately
preceding line; sometimes it's there. Since you haven't shown us that
line, we have no idea what's happening. Showing us the code below the
highlighted error line is of no value; showing us the code before that
line is helpful.

Also: Please don't use Google Groups, or if you must, please clean up
its messes.

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

Re: OOP with MyTime

[Mark Lawrence]

On 03/07/2014 16:21, kjaku...@gmail.com wrote:

On Thursday, July 3, 2014 9:11:49 AM UTC-4, MRAB wrote:


I'm pleased to see that you have answers.  In return would you please 
use the mailing list 
https://mail.python.org/mailman/listinfo/python-list or read and action 
this https://wiki.python.org/moin/GoogleGroupsPython to prevent us 
seeing double line spacing and single line paragraphs, thanks.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

PEP8 and 4 spaces

[Tobiah]

Coworker takes PEP8 as gospel and uses 4 spaces
to indent.  I prefer tabs.  Boss want's us to
unify.  The sole thing you get with spaces as
far as I can tell, is that someone loading the
code into Notepad will still see a 4 character
indent.  That may be true, but that same person
is going to have a difficult time editing the
code.

Anyway, I gave up the 80 char line length long
ago, having little feeling for some dolt on
a Weiss terminal that for some reason needs to
edit my code.  I feel rather the same about the
spaces and tabs, given that most people seem to
be using editors these days that are configurable
to show tabs a four characters.

Any evidence out there that this part of PEP8 is becoming
more optional or even obsolete, as I've heard others
say about the 80 char line length?

Just need ammo for when the hammer of code
unification comes down.

Thanks,

Tobiah
--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP8 and 4 spaces

[Chris Angelico]

On Fri, Jul 4, 2014 at 3:31 AM, Tobiah  wrote:
> Coworker takes PEP8 as gospel and uses 4 spaces
> to indent.  I prefer tabs.  Boss want's us to
> unify.

1) PEP 8 is meant to be guidelines, *not* a set of hard-and-fast rules.
2) Tabs let different people display the indents at different widths.
You want it to look like four spaces? No problem. You think it looks
better at eight? Fine, set your display to eight. Easy.
3) Perhaps most importantly: You don't have to unify. Let your source
control system do the work for you. In git, that's the smudge/clean
filters and gitattributes; I don't know the mechanics in hg, but I'm
sure it'll exist; in other systems, you might have to rig something
up, or dig through the docs. But you should be able to settle on one
thing in source control and let everyone check out files in whatever
way they like.

Personally, I like, use, and recommend, tabs - but the next best thing
to tabs is a consistent number of spaces (preferably four). But if you
can't make your tools handle the difference, you're going to be
putting unnecessary strains on the humans. Let the humans work with
whatever they prefer.

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

Re: PEP8 and 4 spaces

[Roy Smith]

In article ,
 Tobiah  wrote:

> Coworker takes PEP8 as gospel and uses 4 spaces
> to indent.  I prefer tabs.
> [...]
> Just need ammo for when the hammer of code
> unification comes down.

There are so many battles to fight that are worth fighting.  This isn't 
one of them.  Just go with pep-8 and move on to solving real problems.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP8 and 4 spaces

[Peter Otten]

Tobiah wrote:

> Coworker takes PEP8 as gospel and uses 4 spaces
> to indent.  I prefer tabs.  Boss want's us to
> unify.  The sole thing you get with spaces as
> far as I can tell, is that someone loading the
> code into Notepad will still see a 4 character
> indent.  That may be true, but that same person
> is going to have a difficult time editing the
> code.
> 
> Anyway, I gave up the 80 char line length long
> ago, having little feeling for some dolt on
> a Weiss terminal that for some reason needs to
> edit my code.  I feel rather the same about the
> spaces and tabs, given that most people seem to
> be using editors these days that are configurable
> to show tabs a four characters.
> 
> Any evidence out there that this part of PEP8 is becoming
> more optional or even obsolete, as I've heard others
> say about the 80 char line length?
> 
> Just need ammo for when the hammer of code
> unification comes down.

Indentation: more important than what convention is chosen is that a
convention is chosen. Relax and follow your collegue's example.

As to the line length: how do you manage to exceed the 80-char limit? Deep
nesting, long variable names, complex expressions? All of these often make
it worthwhile refactoring the code even with a lot of horizonal space left
blank on the monitor.

Also: you can probably come up with five aspects that affect the quality of 
your company's code more than the above superficial points and that are hard 
to fix. So pick your fights and attack the most relevant issue.

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

Re: PEP8 and 4 spaces

[Toby Shepard]

On 07/03/2014 10:46 AM, Tim Chase wrote:

Any evidence out there that this part of PEP8 is becoming
more optional or even obsolete, as I've heard others
say about the 80 char line length?

Just need ammo for when the hammer of code
unification comes down.


I'm not sure you'll get a whole lot of "PEP8 is optional or
obsolete", though some may protest the 80-char suggestion.

While I prefer tabs for similar reasons you present (I can set them
to display at whatever width is comfortable), I have Vim configured
to expand tabs into spaces so that my code conforms to standards.

If you're really picky about it, just create hooks in your VCS (you
ARE using revision control, right?) that turn
$STANDARD_NUMBER_OF_SPACES into a tabs at checkout, and then revert
tabs back to that number of spaces pre-commit.  For git, this SO
post covers it:

http://stackoverflow.com/questions/2316677/can-git-automatically-switch-between-spaces-and-tabs



Very interesting.  Yes, we're using Git.  Thanks for the suggestion.

Tobiah

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

Re: PEP8 and 4 spaces

[Paul Sokolovsky]

Hello,

On Fri, 4 Jul 2014 03:38:27 +1000
Chris Angelico  wrote:

> On Fri, Jul 4, 2014 at 3:31 AM, Tobiah  wrote:
> > Coworker takes PEP8 as gospel and uses 4 spaces
> > to indent.  I prefer tabs.  Boss want's us to
> > unify.
> 
> 1) PEP 8 is meant to be guidelines, *not* a set of hard-and-fast
> rules. 
> 2) Tabs let different people display the indents at different
> widths. 

That's exactly the problem with tabs - whatever you think your code
looks like with tabs, other people will see quite different picture.

Also, most people are not interested in doing mumbo-jumbo with tabs
settings, and have them set to standard 8-char tabs. So, any python
code which uses only tabs for indentation automatically violates
4-space convention (and mixing tabs and spaces is nowadays prohibited
in Python).

Summing up: if you care about other human beings, use spaces. If you
don't care about other human beings, you may use tabs, but other human
beings surely will take how you treat them into account ;-).


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP8 and 4 spaces

[Grant Edwards]

On 2014-07-03, Tobiah  wrote:

> Coworker takes PEP8 as gospel and uses 4 spaces to indent.  I prefer
> tabs.  Boss want's us to unify.  The sole thing you get with spaces
> as far as I can tell, is that someone loading the code into Notepad
> will still see a 4 character indent.

Or any editor at all.

> That may be true, but that same person is going to have a difficult
> time editing the code.

That's true with Notepad, but with dozens of other programming
editors, code indented with spaces will read and edit prefectly.
Not so for tab-indented code.

> Anyway, I gave up the 80 char line length long ago, having little
> feeling for some dolt

Same to you.

> on a Weiss terminal that for some reason needs to edit my code.  I
> feel rather the same about the spaces and tabs, given that most
> people seem to be using editors these days that are configurable to
> show tabs a four characters.
>
> Any evidence out there that this part of PEP8 is becoming more
> optional or even obsolete, as I've heard others say about the 80 char
> line length?
>
> Just need ammo for when the hammer of code unification comes down.

Just do the right thing and configure your editor to indent with
spaces.

-- 
Grant Edwards   grant.b.edwardsYow! Am I SHOPLIFTING?
  at   
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP8 and 4 spaces

[Tim Chase]

> Any evidence out there that this part of PEP8 is becoming
> more optional or even obsolete, as I've heard others
> say about the 80 char line length?
> 
> Just need ammo for when the hammer of code
> unification comes down.

I'm not sure you'll get a whole lot of "PEP8 is optional or
obsolete", though some may protest the 80-char suggestion.

While I prefer tabs for similar reasons you present (I can set them
to display at whatever width is comfortable), I have Vim configured
to expand tabs into spaces so that my code conforms to standards.

If you're really picky about it, just create hooks in your VCS (you
ARE using revision control, right?) that turn
$STANDARD_NUMBER_OF_SPACES into a tabs at checkout, and then revert
tabs back to that number of spaces pre-commit.  For git, this SO
post covers it:

http://stackoverflow.com/questions/2316677/can-git-automatically-switch-between-spaces-and-tabs

-tkc



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

Re: PEP8 and 4 spaces

[Tim Chase]

On 2014-07-03 19:02, Grant Edwards wrote:
> > That may be true, but that same person is going to have a
> > difficult time editing the code.  
> 
> That's true with Notepad, but with dozens of other programming
> editors, code indented with spaces will read and edit prefectly.
> Not so for tab-indented code.

A broken editor isn't the world's best argument.  If I used an editor
that changed my line-endings, randomly altered arbitrary characters,
or tried to compress multiple spaces into one, I'd complain that the
editor was broken.  If a file has tab characters and my editor
doesn't let me properly deal with  characters, then THE EDITOR IS
BROKEN.

That said, even though I'm "-0" on "use 4 spaces rather than tabs", I
conform to the standard to reduce interop headache even if I'd rather
use tabs.

-tkc



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

Re: threading.Condition.wait() is not catching SIGTERM

[Ned Deily]

In article <17f05a1b-44c8-4f25-afe9-5dbcffb99...@gmail.com>,
> I have the following code which when executed waits to be interrupted by 
> SIGINT, SIGTERM or SIGQUIT. When an object is initialized, it creates a 
> threading.Condition() and acquires() it! The program then registers the 
> signal handlers where notify() and release() is called when the above 
> mentioned signals are received. After registering the signal handlers, it 
> calls wait() on the condition variable and block.
> 
> When I tried to stop the program with Ctrl-C, its did not respond. IOW, the 
> _signal_handler() method did not get called.  

I'm not sure what you are trying to do but your test case seems flawed.  
threading.Condition is designed to be used with multiple threads but 
your test doesn't actually use threads.  If you run your test with a 
reasonably current Python 3 (after changing print to print()), you can 
see that it fails (and why it fails) when interrupting with Ctrl-C:

Waiting to be interrupted!
^CReceived terminate request - signal = 2
Traceback (most recent call last):
  File "b.py", line 30, in 
main()
  File "b.py", line 27, in main
a.register_and_wait()
  File "b.py", line 22, in register_and_wait
self._termination_signal.wait()  # control blocks here!
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threadin
g.py", line 289, in wait
waiter.acquire()
  File "b.py", line 13, in _signal_handler
self._termination_signal.notify()
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threadin
g.py", line 339, in notify
raise RuntimeError("cannot notify on un-acquired lock")
RuntimeError: cannot notify on un-acquired lock

After a quick glance, I'm not sure why Python 2.7 is behaving 
differently, e.g. not raising an error, since both versions of 
Condition.notify have the same test so the difference is elsewhere.  
Feel free to open an issue for not catching the error in 2.7 but you 
should rethink what you are trying to do here.

-- 
 Ned Deily,
 n...@acm.org

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

Re: PEP8 and 4 spaces

[Toby Shepard]

On 07/03/2014 12:44 PM, Simon Ward wrote:



On 3 July 2014 18:31:04 BST, Tobiah  wrote:

Coworker takes PEP8 as gospel and uses 4 spaces to indent.  I
prefer tabs.  Boss want's us to unify.


This isn't worth arguing about.


How point of view changes things.




Anyway, I gave up the 80 char line length long ago, having little
feeling for some dolt on a Weiss terminal that for some reason
needs to edit my code.


Putting the code factoring considerations aside, because others have
already mentioned them and I'm sure others will, there are some other
practical reasons for limiting line width:


All that is fine, and makes great sense.  I generally write short lines.
I know the tricks for splitting otherwise long lines into multiple readable
lines.  I'm not advocating that we use semicolons and always go past 80
characters.  I'm just saying that once in a while it makes sense to me
to do it, and I don't lose sleep when it happens.
 

I feel rather the same about the spaces and tabs, given that most
people seem to be using editors these days that are configurable to
show tabs a four characters.


Conversely, those same editors can probably automatically indent and
unindent a configurable amount of spaces. If you don't use such an
editor, and you really can't tolerate the different style, you can
use another tool to reindent your code.


It works both ways.  I'm using Vim, and it will handle the spaces
and give a tab-like experience - not quite as good, but good enough
to live with.  Either of us could give in.  The boss likes tabs,
as I do.  The coworker really only has PEP8 to point to.  There is
really nothing good about the space way, other than as I said, Notepad
users will see four space indents.  Most other users can configure the tabstop
as they like *if* tabs are being used.  The Notepad users will get by just fine.

It could fall either way.  I was just trying to nudge it toward mine.

Tobiah

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

Re: threading.Condition.wait() is not catching SIGTERM

[Roy Smith]

In article ,
 Ned Deily  wrote:

> In article <17f05a1b-44c8-4f25-afe9-5dbcffb99...@gmail.com>,
> > I have the following code which when executed waits to be interrupted by 
> > SIGINT, SIGTERM or SIGQUIT. When an object is initialized, it creates a 
> > threading.Condition() and acquires() it! The program then registers the 
> > signal handlers where notify() and release() is called when the above 
> > mentioned signals are received. After registering the signal handlers, it 
> > calls wait() on the condition variable and block.
> > 
> > When I tried to stop the program with Ctrl-C, its did not respond. IOW, the 
> > _signal_handler() method did not get called.  
> 
> I'm not sure what you are trying to do but your test case seems flawed.  
> threading.Condition is designed to be used with multiple threads but 
> your test doesn't actually use threads.  If you run your test with a 
> reasonably current Python 3 (after changing print to print()), you can 
> see that it fails (and why it fails) when interrupting with Ctrl-C:
> 
> Waiting to be interrupted!
> ^CReceived terminate request - signal = 2
> Traceback (most recent call last):
>   File "b.py", line 30, in 
> main()
>   File "b.py", line 27, in main 
> a.register_and_wait()
>   File "b.py", line 22, in register_and_wait
> self._termination_signal.wait()  # control blocks here!
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threadin
> g.py", line 289, in wait
> waiter.acquire()
>   File "b.py", line 13, in _signal_handler
> self._termination_signal.notify()
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threadin
> g.py", line 339, in notify
> raise RuntimeError("cannot notify on un-acquired lock")
> RuntimeError: cannot notify on un-acquired lock
> 
> After a quick glance, I'm not sure why Python 2.7 is behaving 
> differently, e.g. not raising an error, since both versions of 
> Condition.notify have the same test so the difference is elsewhere.  
> Feel free to open an issue for not catching the error in 2.7 but you 
> should rethink what you are trying to do here.

That's not the whole story.  I was playing around with his example this 
morning (Python 2.7.1, OSX, Darwin Kernel Version 11.4.2).  My original 
thought was that maybe the wait() call is holding the GIL and breaking 
it up into two threads would solve that somehow.  So, I tried this:

-
from signal import signal, SIGINT, SIGTERM, SIGQUIT
from threading import Condition, Thread, current_thread
import time

class A:
def __init__(self):
self._termination_signal = Condition()

def _signal_handler(self, signum, frame):
print "Received terminate request - signal = {0}".format(signum,)
del frame
return

def register_and_wait(self):
t = Thread(target=A.run, args=[self._termination_signal])
t.start()
signal(SIGINT, self._signal_handler)
signal(SIGTERM, self._signal_handler)
signal(SIGQUIT, self._signal_handler)

@staticmethod
def run(ts):
ts.acquire(blocking=0)
print "Waiting to be interrupted!"
ts.wait()  # control blocks here!   


print "Notified!!"

def main():
a = A()
a.register_and_wait()

if __name__ == "__main__":
main()
---

I got the same result: _signal_handler() never gets called.  You may be 
right that at the point where notify() gets called, you don't have a 
lock, but that's moot because you never even get to that point.  That's 
the fundamental problem here, and it sure smells like a deadlock.  And 
since it happens even in the non-threaded version, my nose says it's 
somehow GIL related.

I just noticed that the acquire call is documented as taking 
specifically True or False, not generically something truthy or falsey.  
I tried it again with accept(blocking=False) and got the same result.

Hmmm, I just also noticed what I think is a bug in the docs 
(https://docs.python.org/2/library/threading.html).  It says, "If a call 
with blocking set to True would block, return False immediately".  Isn't 
that backwards?  Doesn't that describe the blocking=False behavior?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP8 and 4 spaces

[Simon Ward]

On 3 July 2014 18:31:04 BST, Tobiah  wrote:
>Coworker takes PEP8 as gospel and uses 4 spaces
>to indent.  I prefer tabs.  Boss want's us to
>unify.

This isn't worth arguing about. Pick a convention, it's probably going to be a 
compromise, get used to it. PEP8 is as good a base as any, and is (mostly) 
directly supported by various syntax checking tools such as flake8 and pylama 
(which I think both use the pep8 tool underneath), and the modes of various 
editors. Any good editor will make indentation painless, whichever method you 
settle on.

>Anyway, I gave up the 80 char line length long
>ago, having little feeling for some dolt on
>a Weiss terminal that for some reason needs to
>edit my code.

Putting the code factoring considerations aside, because others have already 
mentioned them and I'm sure others will, there are some other practical reasons 
for limiting line width:

I often use multiple editors side-by-side or in split window mode. If I'm 
limited to one screen I'll probably also have documentation open on that 
screen. Having to side scroll, or have a single editor take up most of the 
width of the display forcing switching between windows, seems to me to be more 
harmful than good for productivity.

There is plenty of research on the readability of prose, less so on code, but 
some of the considerations apply to code too. I'll pick out three of them.

The first probably applies less to code (because code is generally line-based 
and the line widths vary; it's not just a big wall of text): people tend to 
find it harder to track from one line to the next with longer lines of text.

The second has to do with focus: as the reader continues along a line of text 
their focus dwindles, it seems that starting a new line renews focus.

Thirdly, it may seem unintuitive given that we appear to have more capacity for 
horizontal movement of the eyes, but excessively long lines can cause more work 
for them potentially inducing eyestrain. We focus near the centre. Our 
peripheral vision either side is less discerning of details and more on 
movement (such as an attacker). We must move our eyes to continue reading long 
lines, and possibly even move our heads. This is a problem for vertical 
movement too, and happens if lines are too short. (I have no idea how this 
affects readers of vertical scripts.)

> I feel rather the same about the
>spaces and tabs, given that most people seem to
>be using editors these days that are configurable
>to show tabs a four characters.

Conversely, those same editors can probably automatically indent and unindent a 
configurable amount of spaces. If you don't use such an editor, and you really 
can't tolerate the different style, you can use another tool to reindent your 
code.

Simon
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP8 and 4 spaces

[Tobiah]

On 07/03/2014 12:40 PM, Tim Chase wrote:

On 2014-07-03 19:02, Grant Edwards wrote:

That may be true, but that same person is going to have a
difficult time editing the code.


That's true with Notepad, but with dozens of other programming
editors, code indented with spaces will read and edit prefectly.
Not so for tab-indented code.


A broken editor isn't the world's best argument.  If I used an editor
that changed my line-endings, randomly altered arbitrary characters,
or tried to compress multiple spaces into one, I'd complain that the
editor was broken.  If a file has tab characters and my editor
doesn't let me properly deal with  characters, then THE EDITOR IS
BROKEN.

That said, even though I'm "-0" on "use 4 spaces rather than tabs", I
conform to the standard to reduce interop headache even if I'd rather
use tabs.

-tkc



I think your suggestion of having GIT handle the transformations
is the way we'll go.  nothing to quibble or worry about.  Well put
spaces in the repository since it still seems to be the community's
preference and I'll convert to tabs with GIT on the fly.  Problem
solved.

Thanks,

Tobiah

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

Re: PEP8 and 4 spaces

[Tobiah]

Anyway, I gave up the 80 char line length long ago, having little
feeling for some dolt


Same to you.


Haha, the language was too strong.  The code I'm talking about is
only going to be seen by a small group of programmers.  The current
trio has all been here for over 20 years.  I'd be more concerned if
the code were ever to be made public.


on a Weiss terminal that for some reason needs to edit my code.  I
feel rather the same about the spaces and tabs, given that most
people seem to be using editors these days that are configurable to
show tabs a four characters.

Any evidence out there that this part of PEP8 is becoming more
optional or even obsolete, as I've heard others say about the 80 char
line length?

Just need ammo for when the hammer of code unification comes down.


Just do the right thing and configure your editor to indent with
spaces.



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

Re: general module auditing

[Rita]

On Thu, Jul 3, 2014 at 8:36 AM, Mark Lawrence 
wrote:

> On 03/07/2014 10:27, Rita wrote:
>
>>
>>
>>
>> On Thu, Jul 3, 2014 at 2:54 AM, Mark Lawrence > > wrote:
>>
>> On 03/07/2014 02:17, Rita wrote:
>>
>>
>> On Wed, Jul 2, 2014 at 2:46 PM, Irmen de Jong
>> mailto:irmen.nos...@xs4all.nl>
>> >
>> __>> wrote:
>>
>>  On 2-7-2014 4:04, Rita wrote:
>>   > yes, this helps. But I want to know who uses the module,
>> serpent.
>>  So, when
>>   > I upgrade it or remove it they won't be affected
>> adversely.
>>
>>  (Please don't top-post, it makes the discussion harder to
>> follow.)
>>
>>   > On Tue, Jul 1, 2014 at 2:16 PM, Irmen de Jong
>>  mailto:irmen.nos...@xs4all.nl>
>> > >__>>
>>
>>
>>   > wrote:
>>   >
>>   >> On 1-7-2014 12:38, Rita wrote:
>>   >>> i work in a group of developers (15 or so)  who are
>> located
>>  globally. I
>>   >>> would like to know what modules everyone is uses if I
>> ever have to
>>   >> upgrade
>>   >>> my python. Is there mechanism which will let me see who
>> is
>>  using what?
>>   >>>
>>   >>> ie,
>>   >>>
>>   >>> tom,matplotlib
>>   >>> bob, pylab
>>   >>> nancy, numpy
>>   >>> nancy, matplotlib
>>   >>>
>>   >>> etc...
>>   >>>
>>   >>>
>>   >>
>>   >> Well, if your group is all using Pip (and perhaps even
>>  virtualenv), you
>>   >> could use pip
>>   >> list. In my case:
>>   >>
>>   >> $ pip list
>>
>>  [...]
>>
>>
>>  Why would the fact that you upgrade or remove a package,
>> affect
>>  another developer in
>>  your group? Are you all using the same machine to develop
>> on, with
>>  one Python installation?
>>
>>  I think you'll have to tell us some more details about the
>> way you
>>  work together before
>>  we can give a meaningful answer to your question.
>>
>>  Irmen
>>
>>  --
>> https://mail.python.org/__mailman/listinfo/python-list
>>
>> 
>>
>> we have a shared mount point which has our python install. we
>> have 3
>> servers on one part of the campus  and 2 in another part.
>>
>> I want to find out what packages our user base is using thats
>> the final
>> goal. I can figure out who is using python by writing a wrapper
>> but not
>> what module.
>>
>> --
>> --- Get your facts first, then you can distort them as you
>> please.--
>>
>>
>> You can check every users's program for import statements but do you
>> really need to, why not check what's in the site-packages folder for
>> your python install?
>>
>> --
>> My fellow Pythonistas, ask not what our language can do for you, ask
>> what you can do for our language.
>>
>> Mark Lawrence
>>
>> how can i get frequency of the module usage? thats the end goal.
>>
>> --
>> --- Get your facts first, then you can distort them as you please.--
>>
>>
>>
> Count the number of imports or count the times a given program gets run
> for the number of imports depending on what you mean.
>
>
> --
> My fellow Pythonistas, ask not what our language can do for you, ask what
> you can do for our language.
>
> Mark Lawrence
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>

here is what I am doing now,

egrep 'from|import' *.py | wc -l which is giving me that. But this does not
give me the number of times the particular module gets called. I was
thinking of adding a logging feature to all of my modules so every time
they get called it will be written to a log file with corresponding host
and username. Is there an easy way to do that?



-- 
--- Get your facts first, then you can distort them as you please.--
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP8 and 4 spaces

[Emile van Sebille]

On 7/3/2014 2:23 PM, Tobiah wrote:

I think your suggestion of having GIT handle the transformations
is the way we'll go.  nothing to quibble or worry about.  Well put
spaces in the repository since it still seems to be the community's
preference and I'll convert to tabs with GIT on the fly.  Problem
solved.


Just watch out for mixed tabs and spaces in the same file -- a tab 
counts as eight spaces and can be used interchangeably in python2.


Emile



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

Re: general module auditing

[Mark Lawrence]

On 04/07/2014 00:09, Rita wrote:


here is what I am doing now,

egrep 'from|import' *.py | wc -l which is giving me that. But this does
not give me the number of times the particular module gets called. I was
thinking of adding a logging feature to all of my modules so every time
they get called it will be written to a log file with corresponding host
and username. Is there an easy way to do that?



Start here https://docs.python.org/3/library/logging.html#module-logging

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Get named groups from a regular expression

[Philip Shaw]

On 2014-07-01, Florian Lindner  wrote:
>
> Is there a way I can extract the named groups from a regular
> expression?  e.g. given "(?P\d)" I want to get something
> like ["testgrp"].

The match object has an attribute called "groupdict", so you can get
the found named groups using match.groupdict.keys. I can't remember
what happens to unnamed groups (I prefer to name every group I want),
but ISTR that there is a list of capture groups in which the indexes
are the capture groups number (i.e. what you'd use to backreference
them).

> Can I make the match object to return default values for named
> groups, even if no match was produced?

A lazy solution I've used was to write a default dict, then update it
with the groupdict. I doubt that's all that efficient, but the
defaults were constant strings and the program was network-bound
anyway.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: threading.Condition.wait() is not catching SIGTERM

[Cameron Simpson]

On 03Jul2014 16:43, Roy Smith  wrote:
[...]

Hmmm, I just also noticed what I think is a bug in the docs
(https://docs.python.org/2/library/threading.html).  It says, "If a call
with blocking set to True would block, return False immediately".  Isn't
that backwards?  Doesn't that describe the blocking=False behavior?


If you mean this text under Lock.acquire:

  When invoked with the blocking argument set to False, do not block. If a call 
  with blocking set to True would block, return False immediately; otherwise, 
  set the lock to locked and return True.


that pretty clearly (to me) describes blocking=False, by contrasting it with a 
behaviour that would obtain if blocking=True. It is in the clause describing 
"the blocking argument set to False", after all.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: threading.Condition.wait() is not catching SIGTERM

[Sangeeth Saravanaraj]

On 04-Jul-2014, at 1:43 am, Ned Deily  wrote:

> In article <17f05a1b-44c8-4f25-afe9-5dbcffb99...@gmail.com>,
>> I have the following code which when executed waits to be interrupted by 
>> SIGINT, SIGTERM or SIGQUIT. When an object is initialized, it creates a 
>> threading.Condition() and acquires() it! The program then registers the 
>> signal handlers where notify() and release() is called when the above 
>> mentioned signals are received. After registering the signal handlers, it 
>> calls wait() on the condition variable and block.
>> 
>> When I tried to stop the program with Ctrl-C, its did not respond. IOW, the 
>> _signal_handler() method did not get called.  
> 
> I'm not sure what you are trying to do but your test case seems flawed.  
> threading.Condition is designed to be used with multiple threads but 
> your test doesn't actually use threads.  If you run your test with a 
> reasonably current Python 3 (after changing print to print()), you can 
> see that it fails (and why it fails) when interrupting with Ctrl-C:
> 
> Waiting to be interrupted!
> ^CReceived terminate request - signal = 2
> Traceback (most recent call last):
>  File "b.py", line 30, in 
>main()
>  File "b.py", line 27, in main
>a.register_and_wait()
>  File "b.py", line 22, in register_and_wait
>self._termination_signal.wait()  # control blocks here!
>  File 
> "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threadin
> g.py", line 289, in wait
>waiter.acquire()
>  File "b.py", line 13, in _signal_handler
>self._termination_signal.notify()
>  File 
> "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threadin
> g.py", line 339, in notify
>raise RuntimeError("cannot notify on un-acquired lock")
> RuntimeError: cannot notify on un-acquired lock
> 
> After a quick glance, I'm not sure why Python 2.7 is behaving 
> differently, e.g. not raising an error, since both versions of 
> Condition.notify have the same test so the difference is elsewhere.  
> Feel free to open an issue for not catching the error in 2.7 but you 

Ned, thanks for the explanation. 

I have filed http://bugs.python.org/issue21913 to explore further on this issue.

Thank you,

Sangeeth 

> should rethink what you are trying to do here.
> 
> -- 
> Ned Deily,
> n...@acm.org
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

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

Re: PEP8 and 4 spaces

[Steven D'Aprano]

On Thu, 03 Jul 2014 10:31:04 -0700, Tobiah wrote:

> Coworker takes PEP8 as gospel and uses 4 spaces to indent.  I prefer
> tabs.  Boss want's us to unify.  

Point out to your boss, and your co-worker, that PEP 8 *explicitly* 
states that it is not compulsory except for the standard library, and 
that for third-party and private code, local conventions over-rule PEP 8. 
In other words, if your co-worker is the only one who uses spaces when 
everyone else uses tabs, **he is violating PEP 8**.


> The sole thing you get with spaces as
> far as I can tell, is that someone loading the code into Notepad will
> still see a 4 character indent.  That may be true, but that same person
> is going to have a difficult time editing the code.

Advantages of spaces:
- It's a convention that many people follow.

Disadvantages of tabs:
- Many standard Unix/Linux/POSIX tools have a hard time dealing with tabs.

I call such tools *broken*, and there is a vicious circle going on: 
programmers use the fact that these tools don't support tabs to justify 
the use of spaces, and the majority consensus that you should use spaces 
as justification for not fixing the tools.

As I understand it, Unix coders tend to prefer spaces, and Windows users 
tend to be more comfortable with tabs. This isn't a hard-and-fast rule, 
you'll find plenty of exceptions, but it seems to me that Unix tools are 
unforgiving of tabs while Windows IDEs tend to default to tabs. I'm not a 
Windows person myself, any Windows guys like to comment?



> Anyway, I gave up the 80 char line length long ago, having little
> feeling for some dolt on a Weiss terminal that for some reason needs to
> edit my code.

How do you feel about some dolt who aligns two or three editor windows 
side-by-side so they can compare code? :-)

Being able to set code side-by-side, say in a horizontal diff, or two 
editors next to each other, is a much more important reason to support a 
79+1 maximum line width than Weiss terminals.




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

Re: PEP8 and 4 spaces

[Chris Angelico]

On Fri, Jul 4, 2014 at 11:02 AM, Steven D'Aprano
 wrote:
> As I understand it, Unix coders tend to prefer spaces, and Windows users
> tend to be more comfortable with tabs. This isn't a hard-and-fast rule,
> you'll find plenty of exceptions, but it seems to me that Unix tools are
> unforgiving of tabs while Windows IDEs tend to default to tabs. I'm not a
> Windows person myself, any Windows guys like to comment?

I've worked both platforms extensively, and it's not really as
clear-cut as that. Most Unix tools are perfectly happy with tabs, *as
long as you let them mean eight spaces*; a lot, but not all, have an
option to configure tab width, but you have to specify it to every
program separately.

On the flip side, tab configurability can be a huge feature. There've
been times when I've looked at something with the tab width set to
something insane like 7 or 9 (no, folks, I did not say "7 of 9") to
highlight a display bug or other oddity. Not often, but it has its
uses - and you can't do that if there are actual spaces involved.

Anyone who's using a broken editor should fix it or switch editors.
That's easy. And if you really love your editor, sometimes you can fix
the issue outside it - maybe in a source control hook.

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

Re: PEP8 and 4 spaces

[Steven D'Aprano]

On Thu, 03 Jul 2014 21:07:28 +0300, Paul Sokolovsky wrote:

> Hello,
> 
> On Fri, 4 Jul 2014 03:38:27 +1000
> Chris Angelico  wrote:
> 
>> On Fri, Jul 4, 2014 at 3:31 AM, Tobiah  wrote:
>> > Coworker takes PEP8 as gospel and uses 4 spaces to indent.  I prefer
>> > tabs.  Boss want's us to unify.
>> 
>> 1) PEP 8 is meant to be guidelines, *not* a set of hard-and-fast rules.
>> 2) Tabs let different people display the indents at different widths.
> 
> That's exactly the problem with tabs - whatever you think your code
> looks like with tabs, other people will see quite different picture.

Why do you consider this a problem?

The only rational reason I can think of is that you are concerned about 
line widths. If I write code with tabs set to two spaces, indent five 
times, and then write 50 characters of code, I'll see a total line width 
of 60 columns. Somebody who views tabs as four spaces will see a width of 
70, and someone else who views them as eight spaces will see a width of 
90 columns. So I can see that's somewhat of a problem, but not a huge one.


> Also, most people are not interested in doing mumbo-jumbo with tabs
> settings, and have them set to standard 8-char tabs. So, any python code
> which uses only tabs for indentation automatically violates 4-space
> convention

"Mumbo-jumbo"? In any decent editor, it's a single setting. In kwrite I 
go Settings > Configure Editor, click the Editing icon, and there's a 
"Tab width" field right there. Hardly mumbo-jumbo.

In any case, the 4-space convention is just a convention. If you're 
willing to go against PEP 8 and use tabs, going against PEP 8 and using 8-
column tab settings shouldn't worry you.


> (and mixing tabs and spaces is nowadays prohibited in Python).

Yes, that's because the algorithm used by the parser to determine the 
indentation level may not give the same answer as a human reader, in the 
presence of mixed tabs and spaces. In any case, in the entire history of 
the space/tab argument, I'm not aware of a single person who recommended 
mixed space/tabs for indents. There are two standard solutions for the 
problem of indenting code, not three: use spaces, or use tabs, but not 
"arbitrarily pick one or the other each time you indent".


> Summing up: if you care about other human beings, use spaces. If you
> don't care about other human beings, you may use tabs, but other human
> beings surely will take how you treat them into account ;-).

Ha ha, that's funny, I would have said the opposite: if you care about 
keeping tools that expect spaces happy, use spaces, if you care about 
allowing people to configure the look of your code, or poor unfortunates 
who aren't using a programmer's editor, use tabs.


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

Re: PEP8 and 4 spaces

[Chris Angelico]

On Fri, Jul 4, 2014 at 11:21 AM, Steven D'Aprano
 wrote:
>> Summing up: if you care about other human beings, use spaces. If you
>> don't care about other human beings, you may use tabs, but other human
>> beings surely will take how you treat them into account ;-).
>
> Ha ha, that's funny, I would have said the opposite: if you care about
> keeping tools that expect spaces happy, use spaces, if you care about
> allowing people to configure the look of your code, or poor unfortunates
> who aren't using a programmer's editor, use tabs.

Right. And hey. If you're a sufficiently competent programmer, you CAN
get away with not caring about other human beings: either because
you're so utterly valuable that people accept you despite your rough
edges... or because you just script away the differences :)

Now, if your *boss* doesn't understand about these things, it's
possible to lose your job over stupid stuff like style guides.
Although to be fair, I'd been planning to quit for a long time, and
the style guide was the last in a long line of problems, so when I
kicked back and said basically "No, your style guide is a bad idea",
it ended up with us parting ways. But that's a separate point.

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

Re: PEP8 and 4 spaces

[Roy Smith]

In article ,
 Chris Angelico  wrote:

> On Fri, Jul 4, 2014 at 11:21 AM, Steven D'Aprano
>  wrote:
> >> Summing up: if you care about other human beings, use spaces. If you
> >> don't care about other human beings, you may use tabs, but other human
> >> beings surely will take how you treat them into account ;-).
> >
> > Ha ha, that's funny, I would have said the opposite: if you care about
> > keeping tools that expect spaces happy, use spaces, if you care about
> > allowing people to configure the look of your code, or poor unfortunates
> > who aren't using a programmer's editor, use tabs.
> 
> Right. And hey. If you're a sufficiently competent programmer, you CAN
> get away with not caring about other human beings: either because
> you're so utterly valuable that people accept you despite your rough
> edges... or because you just script away the differences :)
> 
> Now, if your *boss* doesn't understand about these things, it's
> possible to lose your job over stupid stuff like style guides.
> Although to be fair, I'd been planning to quit for a long time, and
> the style guide was the last in a long line of problems, so when I
> kicked back and said basically "No, your style guide is a bad idea",
> it ended up with us parting ways. But that's a separate point.
> 
> ChrisA

The way I figure it, there are two things which have sucked up more 
time, effort, and productivity than anything else.  Buffer overrun bugs, 
and arguments about whitespace (and placement of braces in those sorts 
of languages).  I'm not sure which order they go in.

Solving buffer overruns is easy; you use bounds-checked containers, or 
languages which don't expose raw memory.  Killing whitespace arguments 
seems to be a far more intractable problem.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP8 and 4 spaces

[Demian Brecht]

On Jul 3, 2014 10:31 AM, "Tobiah"  wrote:
> Just need ammo for when the hammer of code unification comes down.

One issue that I've encountered in the past (one of the reasons outside of
pep8) that I switched to spaces is when working with libraries other than
your own. If you want to stick print statements, breakpoints or make any
other modifications to the code you're working with, chances are if you're
using tabs in your editor, you're going to run into issues when making
those changes.

Most (of not all) libraries I've worked with use spaces. Pep8 suggests the
use of spaces. New hires who have spent any amount of time in python are
/likely/ most used to using spaces. For those reasons I much prefer spaces
over tabs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: fixing an horrific formatted csv file.

[flebber]

I have taken the code and gone a little further, but I need to be able to 
protect myself against commas and single quotes in names.

How is it the best to do this?

so in my file I had on line 44 this trainer name.

"Michael, Wayne & John Hawkes" 

and in line 95 this horse name.
Inz'n'out

this throws of my capturing correct item 9. How do I protect against this?

Here is current code.

import re
from sys import argv
SCRIPT, FILENAME = argv


def out_file_name(file_name):
"""take an input file and keep the name with appended _clean"""
file_parts = file_name.split(".",)
output_file = file_parts[0] + '_clean.' + file_parts[1]
return output_file


def race_table(text_file):
"""utility to reorganise poorly made csv entry"""
input_table = [[item.strip(' "') for item in record.split(',')]
   for record in text_file.splitlines()]
# At this point look at input_table to find the record indices
output_table = []
for record in input_table:
if record[0] == 'Meeting':
meeting = record[3]
elif record[0] == 'Race':
date = record[13]
race = record[1]
elif record[0] == 'Horse':
number = record[1]
name = record[2]
results = record[9]
res_split = re.split('[- ]', results)
starts = res_split[0]
wins = res_split[1]
seconds = res_split[2]
thirds = res_split[3]
prizemoney = res_split[4]
trainer = record[4]
location = record[5]
print(name, wins, seconds)
output_table.append((meeting, date, race, number, name,
 starts, wins, seconds, thirds, prizemoney,
 trainer, location))
return output_table

MY_FILE = out_file_name(FILENAME)

# with open(FILENAME, 'r') as f_in, open(MY_FILE, 'w') as f_out:
# for line in race_table(f_in.readline()):
# new_row = line
with open(FILENAME, 'r') as f_in, open(MY_FILE, 'w') as f_out:
CONTENT = f_in.read()
# print(content)
FILE_CONTENTS = race_table(CONTENT)
# print new_name
f_out.write(str(FILE_CONTENTS))


if __name__ == '__main__':
pass
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: fixing an horrific formatted csv file.

[Gregory Ewing]

flebber wrote:

so in my file I had on line 44 this trainer name.

"Michael, Wayne & John Hawkes"

and in line 95 this horse name. Inz'n'out

this throws of my capturing correct item 9. How do I protect against this?


Use python's csv module to read the file. Don't try to
do it yourself; the rules for handling embedded commas
and quotes in csv are quite complicated. As long as
the file is a well-formed csv file, the csv module
should parse fields like that correctly.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP8 and 4 spaces

[Gregory Ewing]

Steven D'Aprano wrote:

Disadvantages of tabs:
- Many standard Unix/Linux/POSIX tools have a hard time dealing with tabs.

I call such tools *broken*,


They're not broken, they're just using a different set of
conventions. Unix traditionally uses tab characters as a
form of space compression. The meaning of a tab is fixed,
and configurable indentation is done by inserting a suitable
combination of tabs and spaces.

As long as *all* your tools follow that convention, everything
is fine. The problems arise when you mix in tools that use
different conventions.

The truly broken tools IMO are things like mail handlers that
shrink away in terror when they see a tab and remove it
altogether. There's no excuse for that, as far as I can see.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list