Re: [Python-Dev] STM and python

2011-12-06 Thread Armin Rigo
Hi,

Actually, not even one month ago, Intel announced that its processors
will offer Hardware Transactional Memory in 2013:

http://www.h-online.com/newsticker/news/item/Processor-Whispers-About-Haskell-and-Haswell-1389507.html

So yes, obviously, it's going to happen.


A bientôt,

Armin.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] STM and python

2011-12-06 Thread Matt Joiner
This is very interesting, cheers for the link.

On Tue, Dec 6, 2011 at 8:55 PM, Armin Rigo  wrote:
> Hi,
>
> Actually, not even one month ago, Intel announced that its processors
> will offer Hardware Transactional Memory in 2013:
>
> http://www.h-online.com/newsticker/news/item/Processor-Whispers-About-Haskell-and-Haswell-1389507.html
>
> So yes, obviously, it's going to happen.
>
>
> A bientôt,
>
> Armin.



-- 
ಠ_ಠ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Python-checkins] cpython (2.7): PDB now will properly escape backslashes in the names of modules it executes.

2011-12-06 Thread Jason R. Coombs
Éric, These are all good suggestions. I'll make them at some point.

Thanks.

> -Original Message-
> From: python-dev-bounces+jaraco=jaraco@python.org [mailto:python-
> dev-bounces+jaraco=jaraco@python.org] On Behalf Of Éric Araujo
> Sent: Friday, 18 November, 2011 10:10
> To: python-dev@python.org
> Subject: Re: [Python-Dev] [Python-checkins] cpython (2.7): PDB now will
> properly escape backslashes in the names of modules it executes.
> 
> Hi Jason,
> 
> > http://hg.python.org/cpython/rev/f7dd5178f36a
> > branch:  2.7
> > user:Jason R. Coombs 
> > date:Thu Nov 17 18:03:24 2011 -0500
> > summary:
> >   PDB now will properly escape backslashes in the names of modules it
> > executes. Fixes #7750
> 
> > diff --git a/Lib/test/test_pdb.py b/Lib/test/test_pdb.py
> > +class Tester7750(unittest.TestCase):
> I think we have an unwritten rule that test class and method names should
> tell something about what they test.  (We do have things like TestWeirdBugs
> and test_12345, but I don’t think it’s a useful pattern to follow :)  Not a 
> big
> deal anyway.
> 
> > +# if the filename has something that resolves to a python
> > +#  escape character (such as \t), it will fail
> > +test_fn = '.\\test7750.py'
> > +
> > +msg = "issue7750 only applies when os.sep is a backslash"
> > +@unittest.skipUnless(os.path.sep == '\\', msg)
> > +def test_issue7750(self):
> > +with open(self.test_fn, 'w') as f:
> > +f.write('print("hello world")')
> > +cmd = [sys.executable, '-m', 'pdb', self.test_fn,]
> > +proc = subprocess.Popen(cmd,
> > +stdout=subprocess.PIPE,
> > +stdin=subprocess.PIPE,
> > +stderr=subprocess.STDOUT,
> > +)
> > +stdout, stderr = proc.communicate('quit\n')
> > +self.assertNotIn('IOError', stdout, "pdb munged the
> > + filename")
> Why not check for assertIn(filename, stdout)?  (In other words, check for
> intended behavior rather than implementation of the erstwhile bug.)
> 
> BTW, I’ve just tested that giving a message argument to assertNotIn (the
> third argument), unittest still displays the other arguments to allow for 
> easier
> debugging.  I didn’t know that, it’s cool!
> 
> > +def tearDown(self):
> > +if os.path.isfile(self.test_fn):
> > +os.remove(self.test_fn)
> In my own tests, I’ve become fond of using “self.addCleanup(os.remove,
> filename)”: It’s shorter that a tearDown and is right there on the line that
> follows or precedes the file creation.
> 
> >  if __name__ == '__main__':
> >  test_main()
> > +unittest.main()
> This looks strange.
> 
> Regards
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-
> dev/jaraco%40jaraco.com


smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Warnings

2011-12-06 Thread Cameron Simpson
On 30Nov2011 22:10, Raymond Hettinger  wrote:
| When updating the documentation, please don't go overboard with warnings.
| The docs need to be worded affirmatively -- say what a tool does and show how 
to use it correctly.
| See http://docs.python.org/documenting/style.html#affirmative-tone

I come to this late, but if we're going after the docs...

At the above link one finds this text:

  This assures that files are flushed [...]

It does not. It _ensures_ that files are flushed. The doco style "affirmative
tone" _assures_. The coding practice _ensures_!

Pedanticly,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

There is one evil which...should never be passed over in silence but be
continually publicly attacked, and that is corruption of the language...
- W.H. Auden
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Warnings

2011-12-06 Thread Raymond Hettinger

On Dec 6, 2011, at 7:23 PM, Cameron Simpson wrote:

>  This assures that files are flushed [...]
> 
> It does not. It _ensures_ that files are flushed. The doco style "affirmative
> tone" _assures_. The coding practice _ensures_!
> 
> Pedanticly,
> -- 
> Cameron Simpson 

I can assure you that I've ensured that you're fully insured ;-)

Raymond___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com