On 03.12.2012 11:29, Daniele Varrazzo wrote:
> On Mon, Dec 3, 2012 at 9:01 AM, M.-A. Lemburg wrote:
>> On 03.12.2012 02:42, Daniele Varrazzo wrote:
>>> On Mon, Nov 5, 2012 at 9:28 AM, M.-A. Lemburg wrote:
On 04.11.2012 23:24, Christoph Zwerschke wrote:
> To wrap everything up, as a resul
On Mon, Dec 3, 2012 at 9:01 AM, M.-A. Lemburg wrote:
> On 03.12.2012 02:42, Daniele Varrazzo wrote:
>> On Mon, Nov 5, 2012 at 9:28 AM, M.-A. Lemburg wrote:
>>> On 04.11.2012 23:24, Christoph Zwerschke wrote:
To wrap everything up, as a result of our discussion, I will do the
following
On 03.12.2012 02:42, Daniele Varrazzo wrote:
> On Mon, Nov 5, 2012 at 9:28 AM, M.-A. Lemburg wrote:
>> On 04.11.2012 23:24, Christoph Zwerschke wrote:
>>> To wrap everything up, as a result of our discussion, I will do the
>>> following in the next version of
>>> PyGreSQL:
>>>
>>> * make connecti
On Mon, Nov 5, 2012 at 9:28 AM, M.-A. Lemburg wrote:
> On 04.11.2012 23:24, Christoph Zwerschke wrote:
>> To wrap everything up, as a result of our discussion, I will do the
>> following in the next version of
>> PyGreSQL:
>>
>> * make connections context managers for transactions
>> (may not b
On 05/11/2012 10:28, M.-A. Lemburg wrote:
> On 04.11.2012 23:24, Christoph Zwerschke wrote:
>> > To wrap everything up, as a result of our discussion, I will do the
>> > following in the next version of
>> > PyGreSQL:
>> >
>> > * make connections context managers for transactions
>> > (may not
On 04.11.2012 23:24, Christoph Zwerschke wrote:
> To wrap everything up, as a result of our discussion, I will do the following
> in the next version of
> PyGreSQL:
>
> * make connections context managers for transactions
> (may not be the optimal solution, but it's already established)
> * mak
Am 04.11.2012 19:32, schrieb Michael Bayer:
> IMHO the DBAPI is a low level API that should do just one thing,
> allow rudimental functionality to a relational database with as much
> consistency as possible.
Essentially agreed, but I think it's excusable for SQLite as a
light-weight database to
On Nov 4, 2012, at 6:37 AM, Christoph Zwerschke wrote:
> Am 04.11.2012 01:11, schrieb Michael Bayer:
> > not to mention "There should be one-- and preferably
> > only one --obvious way to do it."
>
> Which can easily be overtrumped by "simple is better than complex",
> "readability counts", "fl
Am 04.11.2012 01:11, schrieb Michael Bayer:
> not to mention "There should be one-- and preferably
> only one --obvious way to do it."
Which can easily be overtrumped by "simple is better than complex",
"readability counts", "flat is better than nested", and "practicality
beats purity" ;-)
--
Am 04.11.2012 00:07, schrieb M.-A. Lemburg:
> * The short-cuts don't make the underlying cursors available for
> error handling.
>
> * The shortcut methods only work for non result-set generating
> SQL statements, since there's no way to fetch the result sets
> without access to th
On 11/2/12 5:53 AM, Christoph Zwerschke wrote:
> What I find a bit ugly about this approach is that now the context
> managers of connections and cursors behave differently, and that code
> written using these context managers is not self-explanatory. If
> connections and cursors would just have cl
On Nov 3, 2012, at 7:07 PM, M.-A. Lemburg wrote:
>
> Overall, it boils down to "explicit is better than implicit".
not to mention "There should be one-- and preferably only one --obvious way to
do it."
___
DB-SIG maillist - DB-SIG@python.org
http:
On 03.11.2012 23:50, Christoph Zwerschke wrote:
> Am 03.11.2012 20:56, schrieb M.-A. Lemburg:
>> That said, using connections as context managers in the described
>> way is popular and probably already a standard practice, so I
>> guess it's better to standardize on it and document it properly,
>>
Am 03.11.2012 20:56, schrieb M.-A. Lemburg:
> That said, using connections as context managers in the described
> way is popular and probably already a standard practice, so I
> guess it's better to standardize on it and document it properly,
> rather than leaving it open for interpretation - even
On 02.11.2012 10:53, Christoph Zwerschke wrote:
> ...
> What I find a bit ugly about this approach is that now the context managers
> of connections and
> cursors behave differently, and that code written using these context
> managers is not
> self-explanatory. If connections and cursors would j
Christoph, I think you may be Dutch -- your design proposal feels right to
me.
(+1) from Vernon
On Fri, Nov 2, 2012 at 3:53 AM, Christoph Zwerschke wrote:
>
> What I find a bit ugly about this approach is that now the context
> managers of connections and cursors behave differently, and that cod
Am 02.11.2012 01:15, schrieb Vernon Cole:
> I've been scratching my head over this question, too. Someone
> (Christoph?) please craft for us a little sample program, as small as
> possible, showing how this ought to look in practice.
The implementation would be like this:
class ConnectionWithCo
I've been scratching my head over this question, too. Someone (Christoph?)
please craft for us a little sample program, as small as possible, showing
how this ought to look in practice.
It ought to be obvious (see PEP 20 aphorism 13) but I am in need of a Dutch
person (see PEP 20 aphorism 14) to
On Thursday 2012-11-01 08:57 (-0700), M.-A. Lemburg wrote:
Christoph Zwerschke wrote:
We're currently preparing a new release of PyGreSQL and want to make use of
context managers. My
obvious idea was to let connections and cursors act as context managers that
just close themselves,
and add a
Christoph Zwerschke wrote:
> We're currently preparing a new release of PyGreSQL and want to make use of
> context managers. My
> obvious idea was to let connections and cursors act as context managers that
> just close themselves,
> and add an extra context manager in form of a "transaction" pro
On Nov 1, 2012, at 10:01 AM, Christoph Zwerschke wrote:
> We're currently preparing a new release of PyGreSQL and want to make use of
> context managers. My obvious idea was to let connections and cursors act as
> context managers that just close themselves, and add an extra context manager
>
21 matches
Mail list logo
