date:20121001

[issue1185124] pydoc doesn't find all module doc strings

2012-10-01 Thread Manuel Pégourié-Gonnard


Changes by Manuel Pégourié-Gonnard m...@elzevir.fr:


--
nosy: +mpg

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1185124
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8800] add threading.RWLock

2012-10-01 Thread Sebastian Noack


Sebastian Noack added the comment:

Yes, you could also look at the shared/exclusive lock as one lock with 
different states. But this approach is neither more common, have a look at 
Java's ReadWriteLock [1] for example, which works just like my patch does, 
except that a factory is returned instead of a tuple. Nor does it provide any 
of the benefits, I have mentioned before (same API as Lock and RLock, better 
compatibility with existing code an with statement, ability to pass the shared 
or exclusive lock separetly around). But maybe we could satisfy anybody, by 
following Richard's and Antoine's suggestion of returning a named tuple. So you 
could use the ShrdExclLock both ways:

# use a single object
lock = ShrdExclLock()

with lock.shared:
  ...

with lock.exclusive:
  ...

# unpack the the object into two variables and pass them separately around
shrd_lock, excl_lock = ShrdExclLock()

Thread(target=reader, args=(shrd_lock,)).start()
Thread(target=writer, args=(excl_lock,)).start)


The majority of us seems to prefer the terms shared and exclusive. However I 
can't deny that the terms read and write are more common, even though there are 
also notable exmples where the terms shared and exclusive are used [2] [3]. But 
let us ignore how other call it for now, and get to the origin of both set of 
terms, in order to figure out which fits best into Python:

shared/exclusive - abstract description of what it is
read/write   - best known use case

The reason why I prefer the terms shared and exculsive, is that it is more 
distinct and less likely to get misunderstand. Also naming a generic 
implementation after a specific use case is bad API design and I don't know any 
other case where that was done, in the Python core library.


[1] 
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReadWriteLock.html
[2] http://www.postgresql.org/docs/9.2/static/explicit-locking.html
[3] http://www.unix.com/man-page/freebsd/9/SX/

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8800
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14783] Make int() and str() docstrings correct

2012-10-01 Thread Chris Jerdonek


Chris Jerdonek added the comment:

Attaching proposed patch.  This updates the docstrings for int() and str(), as 
well as for range() and slice() in a similar way.

It also makes the documentation for str() closer to that of the docstring.  The 
documentation for int(), range(), and slice() has already been updated along 
the lines of this patch.

--
keywords: +needs review
stage: needs patch - patch review
Added file: http://bugs.python.org/file27370/issue-14783-1-default.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14783
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8800] add threading.RWLock

2012-10-01 Thread Sebastian Noack


Sebastian Noack added the comment:

@richard: I'm sorry, but both of my patches contain changes to 
'Lib/threading.py' and can be applied on top of Python 3.3.0. So can you 
explain what do you mean, by missing the changes to threading.py?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8800
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8800] add threading.RWLock

2012-10-01 Thread Kristján Valur Jónsson

Kristján Valur Jónsson added the comment:

Personally, I would prefer to make the shared and exclusive locks
attributes of the same object, so one could do

with selock.shared:
...

with selock.exclusive:
...
Please note, the same object could simply be a namedtuple instance.
With this, you are stuck with employing a context manager model only. You
loose the flexibility to do explicit acquire_read() or acquire_write().
My latest patch has methods shared_lock(), exclusive_lock() that return proxy
lock objects that can be used like context managers like you describe, but you
still have the flexibility of using the lock manually.

As for the bikeshedding, let's look at the list of concrete implementations out
there:
Windows: SRW locks (slim reader writer)
http://msdn.microsoft.com/en-us/library/windows/desktop/aa904937(v=vs.85).aspx
Pthreads: rwlock_t (reader/writer)
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/apis/users_86.htm
Java: ReadWriteLock,
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReadWriteLock.html

Am I missing anything?
Don't see why we need to adopt a completly different name or idiom to what
people are used to. Also, note that the java version is quite similar to
Richard's proposal.

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8800
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

1 2 >

1 - 100 of 106 matches

Mail list logo