On 3/28/06, Gerhard Häring [EMAIL PROTECTED] wrote:
Even better, the authors should be willing to keep the version in
Python synchronized with the separate release.
In particular, I would then synchronize changes that have proven stable
in the standalone release to the Python core sqlite
Neal Norwitz wrote:
On 3/28/06, Gerhard Häring [EMAIL PROTECTED] wrote:
Even better, the authors should be willing to keep the version in
Python synchronized with the separate release.
In particular, I would then synchronize changes that have proven stable
in the standalone release to the
On Wednesday 29 March 2006 06:33, Georg Brandl wrote:
Fredrik Lundh wrote:
db.sqlite3 ?
That would make sense if inclusion of more database-related modules
was planned.
My only concern about this is that it wouldn't be possible for other
authors to provide 3rd party packages as (for
Neal Norwitz wrote:
On 3/28/06, Gerhard Häring [EMAIL PROTECTED] wrote:
Even better, the authors should be willing to keep the version in
Python synchronized with the separate release.
In particular, I would then synchronize changes that have proven stable
in the standalone release to the
Anthony Baxter wrote:
db.sqlite3 ?
That would make sense if inclusion of more database-related modules
was planned.
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
Hi Greg,
On Wed, Mar 29, 2006 at 12:38:55PM +1200, Greg Ewing wrote:
I'm really thinking more about the non-inplace operators.
If nb_add and sq_concat are collapsed into a single slot,
it seems to me that if you do
a = [1, 2, 3]
b = array([4, 5, 6])
c = a + b
then a will be
Paul Moore wrote:
On 3/29/06, Brett Cannon [EMAIL PROTECTED] wrote:
Without a direct reason in terms of the language needing a
standardization of an interface, perhaps we just don't need views. If
people want their iterator to have a __len__ method, then fine, they
can add it without
Nick Coghlan wrote:
a message to the wrong list
Darn, I'd hoped I'd caught that in time :(
Sorry folks.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
Guido van Rossum wrote:
On 3/28/06, Charles Cazabon [EMAIL PROTECTED] wrote:
It might be worth instead adding an option flag to the executable that
implies
from the loaded module, run __main__() with sys.argv as its argument(s), so
the user can get this behaviour with `python -X
Barry, go ahead with PySet_Clear().
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
On Wed, 2006-03-29 at 00:01 -0500, Phillip J. Eby wrote:
For some reason, this doesn't bother me with functions. But then, I can't
remember how often I've actually needed to use two decorators on the same
function, or how many times a function decorator's arguments took multiple
lines to
Hi all,
On Tue, Mar 28, 2006 at 09:50:49AM -0800, Guido van Rossum wrote:
C extensions are my main worry -- OTOH if += for a list can already
passes arbitrary types as the argument, then any extension types
should be ready to expect this, right?
Yes, I don't think C extensions are going to
Terry Reedy wrote:
[me:]
For what it's worth[1], I think Raymond is absolutely on crack here.
[Greg Ewing:]
+1 on a good concrete set API from me, too.
[Terry:]
For what it's worth, I think Gareth's crack at Raymond is childish and out
of place here.
Er, it wasn't a crack at Raymond, it
On Wed, 2006-03-29 at 09:35 +0200, Gerhard Häring wrote:
In particular, I would then synchronize changes that have proven stable
in the standalone release to the Python core sqlite module. I think this
is how Barry does it with the email module, too.
I do things a little differently, at
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
because of the way package importing works. And I'd prefer
'database.sqlite' rather than
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
because of the way package importing works. And I'd prefer
'database.sqlite'
On 3/29/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 11:35 PM 3/28/2006 -0500, Fred L. Drake, Jr. wrote:For Zope 3, we have decorators that work with the component architecture (I'msure Phillip is familiar with these).They're used with functions toindicate that the function adapts a particular
Gerhard Häring writes:
db.sql.sqlite is another possibility, if adding something like Durus or
ZODB in the same top-level namespace could be considered for 2.6.
Flat is better than nested. I see no reason why we couldn't have all of
this:
database.sqllite
database.zodb
database.duras
On Wed, Mar 29, 2006 at 07:22:01AM -0800, Michael Chermside wrote:
Flat is better than nested. I see no reason why we couldn't have all of
this:
database.sqllite
database.zodb
database.duras
database.oracle
there's no need to group the SQL databases.
If flat is really so
On Wed, Mar 29, 2006, Fredrik Lundh wrote:
Anthony Baxter wrote:
And I'd prefer 'database.sqlite' rather than 'db.sqlite'.
and extensible_markup_language.document_object_model over
xml.dom, I presume ? ;-)
While I see your point, from my POV xml feels different from db.
Part of it is
Armin Rigo wrote:
Hi Greg,
On Wed, Mar 29, 2006 at 12:38:55PM +1200, Greg Ewing wrote:
I'm really thinking more about the non-inplace operators.
If nb_add and sq_concat are collapsed into a single slot,
it seems to me that if you do
a = [1, 2, 3]
b = array([4, 5, 6])
c = a + b
Georg Brandl wrote:
Generally, I like Trac very much, especially for its interconnected
subsystems.
I've used it with smaller projects, and there it works perfectly.
Having said that, I don't know if the Trac ticket system (which would be the
most important subsystem for us) scales up well
On Wed, 2006-03-29 at 17:52 +0200, Fredrik Lundh wrote:
if this works well for Python 3000, the next step would be to ask them
if they're willing to host the 2.X tracker as well (and optionally the SVN
archive, as well). PSF might not be the Mozilla Foundation, but I'm sure
there's enough
On Wed, 29 Mar 2006 17:52:07 +0200, Fredrik Lundh [EMAIL PROTECTED] wrote:
Georg Brandl wrote:
Generally, I like Trac very much, especially for its interconnected
subsystems.
I've used it with smaller projects, and there it works perfectly.
Having said that, I don't know if the Trac ticket
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 setuptools docs. I'm sure that
editing
On Wed, Mar 29, 2006 at 01:11:06AM -0500, Fred L. Drake, Jr. wrote:
On Wednesday 29 March 2006 00:48, Fred L. Drake, Jr. wrote:
I think the existing usage for classes is perfectly readable. The
@-syntax works well for functions as well.
On re-reading what I wrote, I don't think I
I think short names are more more consistent with the existing naming in
the standard library.
Which doesn't make it a good idea. +1 on adding longer top-level
package names as aliases for existing shorter top-level package names.
Bill
___
Bill Janssen wrote:
I think short names are more more consistent with the existing naming in
the standard library.
Which doesn't make it a good idea. +1 on adding longer top-level
package names as aliases for existing shorter top-level package names.
Which existing short names do you have
Gerhard Häring wrote:
Creating latex docs sounds like I could do it, too. What I'd personally
like to offload are these two tasks:
- integreting pysqlite into the Python build process
- in particular the win32 build process
I would have access to Linux and win32 development machines with
Wolfgang Langner wrote:
It is a Java system. Why promote Java solutions for python ?
I think there are good python solutions for a bug tracker and we
should prefer them.
It is an application. Why worry about its implementation language? If
there are good Python solutions they should be
Gareth McCaughan wrote:
However: if Raymond, or anyone else, is offended, then I'm sorry.
Now, what about the technical issues, as opposed to the way I
happened to introduce my comments?
Proposing that a certain API in an open source project is introduced
for a single customer is indeed a
Gerhard Häring wrote:
In particular, I would then synchronize changes that have proven stable
in the standalone release to the Python core sqlite module. I think this
is how Barry does it with the email module, too.
Sounds all fine to me.
Regards,
Martin
Die, thread.
Do I personally have to go into svn and reject this PEP?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
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)
is easier to read than:
@implements(IFoo)
class Foo:
Docstring
On 3/29/06, Wolfgang Langner [EMAIL PROTECTED] wrote:
[Barry]
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
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
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 point
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-
other
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
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
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'd say
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 need a BDFL
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'll
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 summarize the
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 ?
/F
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's
-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 applications with
[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().
gerald's pysqlite binding
sorry, gerhard.
/F
___
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
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
-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
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
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 in the
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 wrapper
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
[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 and
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 to make
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
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 db for
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 want to
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
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 managed
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
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
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 ?
/F
___
Python-Dev mailing list
Python-Dev@python.org
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 is hoopy
@def
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 Extensible Markup
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? wink
I don't have a problem with reorganising the standard library, but
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 build
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? wink
I don't
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@python.org
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
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 Markup Language
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
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 following the
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 subpackages within
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 search
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 that
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)
is easier to read than:
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
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).
So
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, 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 here, blah blah
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 more
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
pysqlite.
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
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
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! |
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
something
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 to reserve
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
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
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 of a single
[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
the
[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 the
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. fdrake at acm.org
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 data
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: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
[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 *email*. :-)
1 - 100 of 127 matches
Mail list logo
