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
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 rele
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 i
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 standalon
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 p
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 wi
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 witho
Nick Coghlan wrote:
Darn, I'd hoped I'd caught that in time :(
Sorry folks.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
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
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 Raymo
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 l
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 'db.sq
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.sq
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'm>sure Phillip is familiar with these). They're used with functions to>indicate that the function adapts a partic
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 reall
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 o
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])
>>
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
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
Hello,
> 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 opinions.
It is a Java system. Why promote Java solu
At 12:48 AM 3/29/2006 -0500, Fred L. Drake, Jr. wrote:
>Agreed, but... guess we can't have everything. On the other hand, something
>like:
>
> class Foo:
> """Documentation is good."""
>
> @class implements(IFoo)
>
>is not ambiguous. Hmm. It even says what it means. :-)
Int
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
At 07:47 PM 3/29/2006 +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.
See the stdlib module 'pkgutil' for one way around this, that wo
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
Nick Coghlan wrote:
> There are three big use cases:
>
>dict.keys
>dict.values
>dict.items
>
> Currently these all return lists, which may be expensive in
> terms of copying. They all have iter* variants which while
> memory efficient, are far less convenient to work with.
I'm still
> 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
___
Python-
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 yo
Neal Norwitz wrote:
> However, I'm -0 on adding this to 2.5. We've already got a lot of
> changes. I don't want us to keep piling more on. Also I thought I
> saw Gerhard say that there were some other things he wanted to finish
> and the timing might work better for him to defer a bit. Some of
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
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 us
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:
htt
On 3/29/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> 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 expec
On 3/29/06, Tim Hochberg <[EMAIL PROTECTED]> 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])
>
> That's not particularly desirable
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:
>
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
http
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:
> 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
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
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 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, 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
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
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
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
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
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 ?
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'
-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
[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
> 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
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
-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 t
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
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
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
[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
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
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
> 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 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
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 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
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
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
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
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
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
'
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
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 <[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
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
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 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
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
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
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 follow
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
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
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
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)
> >
> >
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).
S
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
> 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 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
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
>> 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
>> 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
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
1 - 100 of 142 matches
Mail list logo
