Neal Norwitz wrote:
> I'm in favor of having Atlassian setup a system to be used for 3k. It
> would be completely experimental and could be completely thrown away
> which should be made clear to Atlassian if we were to do this. I
> would use the system for evaluation.
so what's the advantage of
Hi Tim,
Oups, sorry. I only just realized my mistake and the meaning of your
message.
On Thu, Mar 30, 2006 at 09:27:02AM +0200, Armin Rigo wrote:
> >>> t = (1,2,3)
> >>> t += [4,5,6]
> TypeError: can only concatenate tuple (not "list") to tuple
>
> >>> t += array([4,5,6])
>
On Wed, Mar 29, 2006 at 11:47:10PM +0200, Thomas Wouters wrote:
> Con:
> > * Competing Python wrappers exist
> > * SQLite itself is updated frequently, let alone the wrappers
> > * Build integration risks unknown, possible delay of 2.5?
> > * Another external library to track and maybe have emergen
Greg Ewing wrote:
> Firebird could be a solution to this. It can be
> used in a mode that doesn't need a server, and it
> has no trouble at all with concurrency or large
> amounts of data that I know of.
so a library that doesn't support multiple independent readers/writers on
a single file at al
On Wed, Mar 29, 2006 at 03:35:48PM +0200, Gerhard H?ring wrote:
> Barry Warsaw wrote:
> > On Wed, 2006-03-29 at 19:47 +1100, Anthony Baxter wrote:
> >
> >>My only concern about this is that it wouldn't be possible for other
> >>authors to provide 3rd party packages as (for instance) db.mysqldb
>
On 3/29/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
> I'll just point out that Atlassian has offered us free hosting for a
> Jira/Confluence solution (plus svn and other stuff we may or may not
> want). I personally support this option, but I know (and accept!) that
> there are differing opinion
Hi Tim,
On Wed, Mar 29, 2006 at 08:45:10AM -0700, Tim Hochberg wrote:
> Ouch. Assuming the same path is followed with tuples, I think that this
> means the following behaviour will continue:
>
> >>> t = (1,2,3)
> >>> a = array([4,5,6])
> >>> t += a
> >>> t
> array([5, 7, 9])
I fell into the
> The language choice should only be used as an argument if all else is
> equal. Of course, "hackability" of a particular solution may be a
> criterion too, and there the language choice could matter. But the
> above response sounded like a knee-jerk to me, and IMO needs to be
> rebutted.
>
> --
>
At 11:09 PM 3/29/2006 -0500, Jack Diederich wrote:
>I think we both want class decorators as a more fine grained substitute
>for __metaclass__ (fine grained as in declared per-class-instance instead
>of this-class-and-all-its-children). I can think of three ways class
>decorators are used:
>
>1) r
See http://python.org/sf/1454485 for the gory details. Basically if
you create a unicode array (array.array('u')) and try to append an
8-bit string (ie, not unicode), you can crash the interpreter.
The problem is that the string is converted without question to a
unicode buffer. Within unicode,
At 03:21 PM 3/30/2006 +1200, Greg Ewing wrote:
>Fred L. Drake, Jr. wrote:
> > On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
> > >import db where db.stdlib == True and db.language == "SQL" \
> > > and db.interface == "DBAPI2.0"
> >
> > While we're at it, we could spell import "sele
On 3/29/06, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>
> This is an ideal job for VMWare on an existing linux build machine if
> someone can ante up a win xp and msvc++ license to the cause.
It probably isn't great from a practical point of view if you wanted
to run buildbot for both the server
At 03:09 PM 3/30/2006 +1200, Greg Ewing wrote:
>Well, here's how my use case would look if I had
>class decorators:
>
>@IOClass
>class MyClass:
> ...
>
>Does that count? My decorator wouldn't need any
>arguments, because it looks inside the class for
>all the information it needs. [1]
Gregory P. Smith wrote:
> On Sat, Mar 11, 2006 at 07:08:14PM +0100, Thomas Heller wrote:
>> Martin v. L?wis wrote:
>>> Josiah Carlson told me had has given up getting a Windows
>>> buildbot running, because every time he installed VS.NET
>>> on his machine, the installation would immediately crash.
On Sun, Mar 12, 2006 at 06:48:13PM -0500, Tim Peters wrote:
> [Trent]
> > :)
> > Did you apply the Berkeley DB patches to your db-4.2.52 sources?
>
> Ah, _which_ patches? As with my buildbot Wiki page, I write down
> everything I do if there's a good chance I may need to do it again.
> So, e.g.,
Neal Norwitz wrote:
> The question is how to fix these. test_float and test_struct fail due
> to a Floating Point Exception signal (SIGFPE).
I would hope that there is some way to control the floating point error
mode of the CPU (*). Changing it would be one option; Tim hopefully can
tell us whet
On Sat, Mar 11, 2006 at 07:08:14PM +0100, Thomas Heller wrote:
> Martin v. L?wis wrote:
> > Josiah Carlson told me had has given up getting a Windows
> > buildbot running, because every time he installed VS.NET
> > on his machine, the installation would immediately crash.
> >
> > So if anybody wan
Brett Cannon wrote:
> All of them are for function parameters of function pointers (``void
> (*fn)(void)`` and such) when used in both function prototypes and
> function declarations. Do we fix these ourselves, or do we report
> them to the libffi maintainers (or are whom)?
If you don't have writ
Raymond Hettinger wrote:
> Yes, _PySet_Next() is a good compromise for you and me -- it saves you from
> writing a hack and saves my API from including a bug factory. The only issue
> is
> that Martin thinks it to be a crummy idea.
If it makes everyone happy, I shouldn't be in the way. Of cour
On Wed, Mar 08, 2006 at 03:03:48AM +0100, Thomas Wouters wrote:
> On 3/7/06, "Martin v. L??wis" <[EMAIL PROTECTED]> wrote:
> >
> > Thomas Wouters wrote:
> > > Who 'owns' Modules/_bsddb.c, if anyone?
> >
> > It's a fork of pybsddb, originally contributed by Gregory Smith (*).
> > For all practical p
These issues are on HEAD. There might be some others I missed.
With cc there are at least 2 issues:
* test_file causes interpreter exit due to sys.stdin.seek(-1)
* test_pty fails apparently due to whitespace differences
http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/
On 3/29/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Tim Hochberg wrote:
>
> > Still, perhaps for Py3K it's worth considering
> > if PyNumber_InplaceAdd should only call __iadd__ and __add__, not
> > __radd__. Thus giving the target object complete control during inplace
> > adds.
>
> That's probabl
[Raymond Hettinger]
> > Barry, go ahead with PySet_Clear().
[Barry]
Cool thanks. I think we've also compromised on _PySet_Next(), correct?
Yes, _PySet_Next() is a good compromise for you and me -- it saves you from
writing a hack and saves my API from including a bug factory. The only issue
i
[promted by Phillip Eby's post, but not in response so content snipped]
I think we both want class decorators as a more fine grained substitute
for __metaclass__ (fine grained as in declared per-class-instance instead
of this-class-and-all-its-children). I can think of three ways class
decorators
Hello,
> I think short names are more more consistent with the existing naming in
> the standard library.
>
> +1 on db.sqlite from me.
same for me +1 on db.sqlite
> db.sql.sqlite is another possibility, if adding something like Durus or
> ZODB in the same top-level namespace could be considered
On Mar 27, 2006, at 7:20 AM, Raymond Hettinger wrote:
> Why don't we expose _PySet_Next() for Barry and leave it out of the
> public API
> for everyone else.
There are precedents for adding some functionality to the C API but
not documenting it to ensure "non advanced users" don't get hurt -
Fred L. Drake, Jr. wrote:
> On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
> >import db where db.stdlib == True and db.language == "SQL" \
> > and db.interface == "DBAPI2.0"
>
> While we're at it, we could spell import "select". :-)
Getting off on a tangent here, but I would act
[EMAIL PROTECTED] wrote:
> Greg> There's a big difference between "db" and "em": "db" is an
> Greg> extremely well-known abbreviation, whereas "em" isn't.
>
> Unless you're a typesetter or a TeX hound... :-)
Good point! Still, the fact remains that it's
not a well-known abbreviation for *
On Thursday 30 March 2006 12:15, [EMAIL PROTECTED] wrote:
> Someone was throwing around names like db.sqlite as the place to
> install pysqlite.
Dunno who originally suggested it, but the theory was that there's
some issue with toplevel library namespace pollution. I'm not too
stressed out one
Phillip J. Eby wrote:
> the readability of @decorators on the outside of a class tends
> to suck as the number of decorators and arguments increases.
So do decorators outside a function.
> What's more, I haven't seen anybody posting any counterexamples to show
> that it doesn't suck for common
On Thursday 30 March 2006 12:07, [EMAIL PROTECTED] wrote:
> To many people "SQL" in the name implies "big databases". I know
> from personal experience at work. The powers-that-be didn't want
> to support another database server (we already have Sybase) and
> didn't want our group's experimental
On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
>import db where db.stdlib == True and db.language == "SQL" \
> and db.interface == "DBAPI2.0"
While we're at it, we could spell import "select". :-)
-Fred
--
Fred L. Drake, Jr.
__
[EMAIL PROTECTED] wrote:
> If I want to install Object Craft's Sybase wrapper the
> logical place for it seems like stdlib.db.sybase. But that's not right
> because the Sybase module's not part of the stdlib. Okay, it belongs in
> site.db.sybase. But now we have two different db packages and th
[EMAIL PROTECTED] wrote:
> The powers-that-be didn't want to support
> another database server (we already have Sybase) and didn't want our group's
> experimental data "polluting" the production database, so the folks who
> wanted it went the SQLite/pysqlite route. They were immediately bitten by
Jack Diederich wrote:
> Using metaclasses also required gross hacks like checking
> for a 'DO_NOT_REGISTER' member for subclasses that wanted to inherit from
> a class that had a Register metaclass but didn't want to be registered.
I've just done something like this myself in the last
few days, a
Barry Warsaw wrote:
> On Wed, 2006-03-29 at 16:29 -0500, Raymond Hettinger wrote:
>
>>The story is different for PySet_Update(). Defining it now could get in the
>>way
>>of possible future development for the module (the function may end-up taking
>>a
>>variable length argument list instead o
Phillip J. Eby wrote:
> My comment above was only about readable *placement* of the decorators, not
> the actual syntax.
The placement is part of the syntax...
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridia
Greg> There's a big difference between "db" and "em": "db" is an
Greg> extremely well-known abbreviation, whereas "em" isn't.
Unless you're a typesetter or a TeX hound... :-)
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
Bill Janssen wrote:
> "db" and "em" are too short to be useful context-free abbreviations,
There's a big difference between "db" and "em": "db" is
an extremely well-known abbreviation, whereas "em" isn't.
At the top level of a reorganised package namespace, I
don't think it would be out of place
At 08:00 PM 3/29/2006 -0500, Jack Diederich wrote:
>A function decorator takes a function as an argument and returns something
>(probably a function and maybe even the very same function).
So would class decorators.
>This is exactly what class decorators should do or we should call them
>somethi
I just thought of a possible name for the
Python package repository. We could call
it the PIPE - Python Index of Packages
and Extensions.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Chri
Anthony> All naming in the stdlib is adhoc by it's nature. We choose a
Anthony> name, and then that's it's name. I'm pretty happy with either
Anthony> 'db.sqlite' or 'database.sqlite', really.
Let's slow down here. If we are really going to start putting together a
package infrastruc
Brett> While this is going to require a PEP (which I am willing to
Brett> write), the discussion of adding pysqlite has brought forth some
Brett> discussion on naming and packaging in the stdlub. Perhaps it's
Brett> time to start discussing the Great Library Reorganization that
>> Is it not possible to distribute an empty db package which is then
>> populated with various database eggs (or other similar installation
>> things)?
Phillip> I don't think I understand your question.
Someone was throwing around names like db.sqlite as the place to install
pys
>> I haven't been tracking the pysqlite discussion either, but one con
>> you missed is that regardless of pro #1 people will almost certainly
>> apply it to problems for which it is ill-suited, reflectly poorly on
>> both Python and SQLite.
Fredrik> the arguments keep getting
On Wed, Mar 29, 2006 at 07:23:03PM -0500, Phillip J. Eby wrote:
> At 11:07 AM 3/29/2006 -0800, Guido van Rossum wrote:
> >On 3/28/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > If we're using Zope 3 as an example, I personally find that:
> > >
> > > class Foo:
> > > """Docstring
On 3/29/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 3/29/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
> > from a user perspective, adding this to the standard library is a
> > no-brainer.
> > the only reason not to add it would be if the release managers don't have
> > time to sort out the bu
> Charles Cabazon writes:
Whoops! Should be "Cazabon".
Bill
___
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
On Wed, 2006-03-29 at 19:34 -0500, Barry Warsaw wrote:
> On Wed, 2006-03-29 at 16:29 -0500, Raymond Hettinger wrote:
>
> > The story is different for PySet_Update(). Defining it now could get in
> > the way
> > of possible future development for the module (the function may end-up
> > taking a
On Wed, 2006-03-29 at 16:29 -0500, Raymond Hettinger wrote:
> The story is different for PySet_Update(). Defining it now could get in the
> way
> of possible future development for the module (the function may end-up taking
> a
> variable length argument list instead of a single argument).
S
On Tue, 2006-03-28 at 22:20 -0800, Raymond Hettinger wrote:
> Barry, go ahead with PySet_Clear().
Cool thanks. I think we've also compromised on _PySet_Next(), correct?
I'll follow up on PySet_Update() in a moment.
-Barry
signature.asc
Description: This is a digitally signed message part
At 11:07 AM 3/29/2006 -0800, Guido van Rossum wrote:
>On 3/28/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > If we're using Zope 3 as an example, I personally find that:
> >
> > class Foo:
> > """Docstring here, blah blah blah
> > """
> > implements(IFoo)
> >
> >
Tim Hochberg wrote:
> Still, perhaps for Py3K it's worth considering
> if PyNumber_InplaceAdd should only call __iadd__ and __add__, not
> __radd__. Thus giving the target object complete control during inplace
> adds.
That's probably reasonable, although it would break
the conceptual notion t
Anthony Baxter <[EMAIL PROTECTED]> wrote:
> I don't have a problem with reorganising the standard library, but
> what's the motivation for moving everything under a new root? Is it
> just to allow people to unambigiously get hold of something from the
> stdlib, rather than following the normal sea
On 3/29/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 3/29/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> > On Thursday 30 March 2006 08:39, Brett Cannon wrote:
> > > Here is a place I think we can take a queue from Java. I think we
> > > should have a root package, 'py', and then have subpack
On Thursday 30 March 2006 10:31, Brett Cannon wrote:
> > I don't have a problem with reorganising the standard library,
> > but what's the motivation for moving everything under a new root?
> > Is it just to allow people to unambigiously get hold of something
> > from the stdlib, rather than follow
gcc 4.0.1 on OS X is spitting out some warnings about libffi:
build/temp.darwin-8.5.0-Power_Macintosh-2.5/libffi/include/ffi.h:191:
warning: function declaration isn't a prototype
build/temp.darwin-8.5.0-Power_Macintosh-2.5/libffi/include/ffi.h:204:
warning: function declaration isn't a prototype
Charles Cabazon writes:
> > On the package naming issue: using "em" for "email" would be wrong,
>
> Eh, that should be "import electronic_mail", then. And
> "import simple_mail_transport_protocol_lib".
>
> > just as "db" for "database" would be wrong.
>
> People who are familiar with Extensible
Armin Rigo wrote:
> So if we provide a complete fix, [].__add__(x) will be modified to
> return NotImplemented instead of raising TypeError if x is not a list,
> and then [1,2,3]+array([4,5,6]) will fall back to array.__radd__() as
> before.
Ah, okay. That seems like it would work.
--
Greg
_
Fredrik writes:
> are you aware of the fact that the module implements the "db-api" ?
"db-api" is just an earlier version of the same naming mistake. I'd
be happy with "database_api" instead of database.
Bill
___
Python-Dev mailing list
Python-Dev@pyth
On 3/29/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> On Thursday 30 March 2006 08:39, Brett Cannon wrote:
> > Here is a place I think we can take a queue from Java. I think we
> > should have a root package, 'py', and then have subpackages within
> > that.
>
> org.python.stdlib, surely?
>
> I
On 3/29/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> On Thursday 30 March 2006 08:15, Fredrik Lundh wrote:
> > from a user perspective, adding this to the standard library is a
> > no-brainer. the only reason not to add it would be if the release
> > managers don't have time to sort out the buil
On Thursday 30 March 2006 08:39, Brett Cannon wrote:
> Here is a place I think we can take a queue from Java. I think we
> should have a root package, 'py', and then have subpackages within
> that.
org.python.stdlib, surely?
I don't have a problem with reorganising the standard library, but
Bill Janssen <[EMAIL PROTECTED]> wrote:
>
> On the package naming issue: using "em" for "email" would be wrong,
Eh, that should be "import electronic_mail", then. And
"import simple_mail_transport_protocol_lib".
> just as "db" for "database" would be wrong.
People who are familiar with Extensi
At 10:42 AM 3/30/2006 +1200, Greg Ewing wrote:
>Fred L. Drake, Jr. wrote:
>
> > class Foo:
> > """Documentation is good."""
> >
> > @class implements(IFoo)
>
>That's an interesting idea. It could be applied to
>functions, too:
>
>def myfunc(myargs):
> """Documentation i
Bill Janssen wrote:
> On the package naming issue: using "em" for "email" would be wrong,
> just as "db" for "database" would be wrong.
are you aware of the fact that the module implements the "db-api" ?
___
Python-Dev mailing list
Python-Dev@pytho
Brett Cannon wrote:
> Here is a place I think we can take a queue from Java. I think we
> should have a root package, 'py', and then have subpackages within
> that
At one point Tim Peters and I thought the right spot for python
equivalents of C-coded modules belonged in package "py". Would
'
On Thursday 30 March 2006 08:15, Fredrik Lundh wrote:
> from a user perspective, adding this to the standard library is a
> no-brainer. the only reason not to add it would be if the release
> managers don't have time to sort out the build issues.
Ok - well, I'm willing to work with Gerhard to do t
Anthony Baxter wrote:
> My only concern about this is that it wouldn't be possible for other
> authors to provide 3rd party packages as (for instance) db.mysqldb
> because of the way package importing works. And I'd prefer
> 'database.sqlite' rather than 'db.sqlite'.
Perhaps dbapi2.sqlite?
Tim D
Fred L. Drake, Jr. wrote:
> class Foo:
> """Documentation is good."""
>
> @class implements(IFoo)
That's an interesting idea. It could be applied to
functions, too:
def myfunc(myargs):
"""Documentation is hoopy"
@def biguglydecorator(longconvolutedarglist)
Some
On 3/29/06, Dennis Allison <[EMAIL PROTECTED]> wrote:
>
> Not quite on the same topic, but perhaps it belong there. I think most of
> use use both the stdlib and some selection of other libraries
> (MySQL-Python, ReportLab Toolkit, PyChart, and PyXML, for example). These
> libraries have to be ma
On 3/29/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> from a user perspective, adding this to the standard library is a no-brainer.
> the only reason not to add it would be if the release managers don't have
> time to sort out the build issues.
Agreed. As a SQL user, it feels like a no-brainer t
At 04:00 PM 3/29/2006 -0600, [EMAIL PROTECTED] wrote:
>Is it not possible to distribute an empty db package which is then populated
>with various database eggs (or other similar installation things)?
I don't think I understand your question.
If you are asking whether it's possible to have Java-li
On Wednesday 29 March 2006 08:22, Jean-Paul Calderone wrote:
> >Agreed. pysqlite is solid and widely accepted, and AFAIK has no
> >competition.
>
> FWIW: http://www.rogerbinns.com/apsw.html
Looks interesting, but not being DB-API compliant is a huge issue for
the stdlib. Part of the reason I wan
> from a user perspective, adding this to the standard library is a no-brainer.
> the only reason not to add it would be if the release managers don't have
> time to sort out the build issues.
I agree with Fredrik here.
On the package naming issue: using "em" for "email" would be wrong,
just as "
On behalf of the Python development team and the Python community,
I'm happy to announce the release of Python 2.4.3 (final).
Python 2.4.3 is a bug-fix release. See the release notes at the
website (also available as Misc/NEWS in the source distribution)
for details of the more than 50 bugs squis
Brett Cannon wrote:
> > Wouldn't the newly founded python-3000 mailing list be the perfect place
> > for such major changes?
>
> If you go back and look at Guido's Python 3000 Process email he said
> that the change could occur in 2.6 and then be done for 3000.
> Renaming modules is not that hard
[EMAIL PROTECTED] wrote:
> I haven't been tracking the pysqlite discussion either, but one con you
> missed is that regardless of pro #1 people will almost certainly apply it to
> problems for which it is ill-suited, reflectly poorly on both Python and
> SQLite.
the arguments keep getting more an
Not quite on the same topic, but perhaps it belong there. I think most of
use use both the stdlib and some selection of other libraries
(MySQL-Python, ReportLab Toolkit, PyChart, and PyXML, for example). These
libraries have to be managed independently and installed independently.
It would be n
Phillip> Pro:
Phillip> * SQLite is really nice to have for writing simple applications
Phillip> with small data needs, especially client-side software. It's
Phillip> probably the best-of-breed open source embedded SQL DB right
Phillip> now.
Phillip> * So, having a wrappe
On 3/29/06, Gerhard Häring <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Brett Cannon wrote:
> > While this is going to require a PEP (which I am willing to write),
> > the discussion of adding pysqlite has brought forth some discussion on
> > naming and packaging
On 3/29/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
Pro: [...]Con:* Competing Python wrappers exist
* SQLite itself is updated frequently, let alone the wrappers* Build integration risks unknown, possible delay of 2.5?* Another external library to track and maybe have emergency updates ofAll of t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brett Cannon wrote:
> While this is going to require a PEP (which I am willing to write),
> the discussion of adding pysqlite has brought forth some discussion on
> naming and packaging in the stdlub. Perhaps it's time to start
> discussing the Great
While this is going to require a PEP (which I am willing to write),
the discussion of adding pysqlite has brought forth some discussion on
naming and packaging in the stdlub. Perhaps it's time to start
discussing the Great Library Reorganization that has been discussed
for eons.
Here is a place I
> gerald's pysqlite binding
sorry, gerhard.
___
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
[Gareth McCaughan]
> For what it's worth[1], I think Raymond is absolutely on crack here.
Nope. No mind-altering drugs here. Based on real-word experience, I have
found
PySet_Next() to be a bug factory and do not want it included in the API.
The story is different for PySet_Update(). Definin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phillip J. Eby wrote:
> At 11:36 AM 3/29/2006 -0800, Guido van Rossum wrote:
>> [...] Perhaps one person in favor and one
>> person against could summarize the argument for me?
>
> Pro:
>
> * SQLite is really nice to have for writing simple applicati
Guido van Rossum wrote:
> Unless you've recanted on that already, let me point out that I've
> never seen sqlite, and I've ignored this thread, so I don't know what
> the disagreement is all about.
what disagreement ?
sqlite is a widely used light-weight SQL library (http://www.sqlite.org)
that'
Robert Brewer wrote:
> More Against?:
> Explaining "database is locked" errors (due to SQLite's exposed
> multiple-readers/one-writer design) on a daily basis (FAQ entries
> notwithstanding).
wow. that's one quality argument. what's wrong with you ?
Martin v. Löwis wrote:
> Guido van Rossum wrote:
> > Unless you've recanted on that already, let me point out that I've
> > never seen sqlite, and I've ignored this thread, so I don't
> know what
> > the disagreement is all about. Perhaps one person in favor and one
> > person against could summar
Guido van Rossum wrote:
> Unless you've recanted on that already, let me point out that I've
> never seen sqlite, and I've ignored this thread, so I don't know what
> the disagreement is all about. Perhaps one person in favor and one
> person against could summarize the argument for me? Otherwise I
Phillip J. Eby wrote:
> At 11:36 AM 3/29/2006 -0800, Guido van Rossum wrote:
>>On 3/28/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
>> > I'm happy to work with Gerhard to make this happen. Does it need a
>> > PEP? I'd say "no", but only because things like ElementTree didn't,
>> > either. Does it
At 11:36 AM 3/29/2006 -0800, Guido van Rossum wrote:
>On 3/28/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> > I'm happy to work with Gerhard to make this happen. Does it need a
> > PEP? I'd say "no", but only because things like ElementTree didn't,
> > either. Does it need a BDFL pronouncement? I
On 3/29/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Die, thread.
>
> Do I personally have to go into svn and reject this PEP?
No, just get a procrastinating student to do it.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
On Mar 29, 2006, at 1:38 PM, Martin v. Löwis wrote:
> Given that Barry insists so firmly that there is a need, and that
> this need arises from a significant code simplification that can
> be achieved through the API, the natural conclusion is to add
> the API. That, of course, assumes that you bel
On 3/29/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Watch out for the parochialism! I like Python as much as the next guy
> > (probably more :-) but I'm sensitive to choosing the best solution.
>
> you better make that "good enough", or we'll be stuck with SF for an
On 3/28/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> I'm happy to work with Gerhard to make this happen. Does it need a
> PEP? I'd say "no", but only because things like ElementTree didn't,
> either. Does it need a BDFL pronouncement? I'd say yes.
Unless you've recanted on that already, let me
Guido van Rossum wrote:
> Watch out for the parochialism! I like Python as much as the next guy
> (probably more :-) but I'm sensitive to choosing the best solution.
you better make that "good enough", or we'll be stuck with SF for an-
other hundred years.
> The language choice should only be us
Phillip J. Eby wrote:
> At 10:44 AM 3/29/2006 +0200, Gerhard Häring wrote:
>> Creating latex docs sounds like I could do it, too.
>
> FYI, there's a reST->PythonDoc converter somebody wrote:
>
> http://www.rexx.com/~dkuhlman/rstpythonlatex_intro.html
>
> I'm planning to try it for porting the se
Guido van Rossum wrote:
> Die, thread.
>
> Do I personally have to go into svn and reject this PEP?
After my latest channeling disaster, I was cautious about this one ;)
I'll reject it now.
Georg
___
Python-Dev mailing list
Python-Dev@python.org
http
1 - 100 of 142 matches
Mail list logo
