Re: [Python-Dev] pysqlite for 2.5?
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 module. I think this > is how Barry does it with the email module, too. Everything Gerhard has said sounds good. From what I read it seems that it might be good to add pysqlite to the stdlib eventually. Overall, I'm +0 on the idea. It seems everyone is pretty positive on the concept. 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 these things sounded like API changes which may be more problematic once in the core as we may have stricter rules on backwards compatibility. We also have to convert the doc from ReST to latex. None of these are show stoppers, but it adds to the amount of work we need to do before release. And there's already more work than we can handle. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 Python core sqlite module. I think this >>is how Barry does it with the email module, too. > > Everything Gerhard has said sounds good. From what I read it seems > that it might be good to add pysqlite to the stdlib eventually. > Overall, I'm +0 on the idea. It seems everyone is pretty positive on > the concept. > > 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. My current and future plans for pysqlite are really only additional features, like wrapping the rest of the SQLite API. > Some of these things sounded like API changes which may be more problematic > once in the core as we may have stricter rules on backwards > compatibility. All my plans for pysqlite are adding more methods to the API, so I see no backwards compatibility problems. > We also have to convert the doc from ReST to latex. None of these are > show stoppers, but it adds to the amount of work we need to do before > release. And there's already more work than we can handle. I understand your concern for keeping the amount of work for a 2.5 release manageable. So as Anthony Baxter said he'd like to work with me to make this happen, then I think he and I can try to not overload other people with more work. 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 MS VS2003, but I don't have enough experience with the Python build process to not make stupid mistakes here. -- Gerhard ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 instance) db.mysqldb because of the way package importing works. And I'd prefer 'database.sqlite' rather than 'db.sqlite'. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 Python core sqlite module. I think this >> is how Barry does it with the email module, too. > > Everything Gerhard has said sounds good. From what I read it seems > that it might be good to add pysqlite to the stdlib eventually. > Overall, I'm +0 on the idea. It seems everyone is pretty positive on > the concept. > > 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 > these things sounded like API changes which may be more problematic > once in the core as we may have stricter rules on backwards > compatibility. > > We also have to convert the doc from ReST to latex. None of these are > show stoppers, but it adds to the amount of work we need to do before > release. And there's already more work than we can handle. FWIW, I'd volunteer to convert the doc format. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 importing works. that could be addressed by a plugin facility in db/__init__.py (or by allowing installation tools to add redirection modules to the db directory...) > And I'd prefer 'database.sqlite' rather than 'db.sqlite'. and extensible_markup_language.document_object_model over xml.dom, I presume ? ;-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
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 asked "Please add yourself to b", and a > will say "Okay, I know how to do that!" and promptly > concatenate itself with b. No: there is a difference between + and += for lists. You can only concatenate exactly a list to a list. Indeed: >>> [].__add__((2, 3)) TypeError: can only concatenate list (not "tuple") to list By contrast, list += is like extend() and accepts any iterable. 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. I'll try harder to see if there is a reasonable example whose behavior would change... A bientot, Armin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Iterators for dict keys, values, and items == annoying :)
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 breaking anything, just realize it isn't part of >> the iterator protocol and thus may limit what objects a function can >> accept, but that is there choice. > > Good point. I think we need to start from strong use cases. With > these, I agree that the view concept is a good implementation > technique to consider. But let's not implement views just for the sake > of having them - I'm pretty sure that was never Guido's intention. 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. For Py3k, the intent is to have only one version which produces a view with the memory efficiency of an iterator, but the convenience of a list. To give these views the benefits of having a real list, the following is all that's really needed: 1. implement __len__ (allows bool() and len() to work) - all delegate to dict.__len__ 2. implement __contains__ (allows containment tests to work) - delegate to dict.__contains__ for dict.keys() - use (or fallback to) linear search for dict.values() - check "dict[item[0]] == item[1]" for dict.items() 3. implement __iter__ (allows iteration to work) - make iter(dict.keys()) equivalent to current dict.iterkeys() - make iter(dict.values()) equivalent to current dict.itervalues() - make iter(dict.items()) equivalent to current dict.iteritems() For an immutable view, that's all you need. IOW, take the iterable protocol (an __iter__ that returns a new iterator when invoked) and add __len__ and __contains__ to get a "container" protocol. Given that containment falls back on __iter__ anyway, __len__ is the only essential addition to turn an iterable into a container. Note that adding __len__ to an *iterator* does NOT give you something that would satisfy such a container protocol - invoking __iter__ again does not give you a fresh iterator, so you can't easily iterate repeatedly. With reiterability as a defining characteristic, other niceties become possible (potentially available as a mixin): 1. a generic container __str__ (not __repr__!) implementation: def __str__(self): # keep default __repr__ since eval(repr(x)) won't round trip name = self.__name__ guts = ", ".join(repr(x) for x in self) return "%s([%s])" % guts 2. generic container value based equality testing: def __eq__(self, other): if len(self) != len(other): return False for this, that in izip(self, other): if this != that: return False return True Further refinement of such a container protocol to the minimal requirements for a sequence protocol is already defined by such things as the requirements of the reversed() builtin: for i, x in enumerate(seq): assert seq[i] == x Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Iterators for dict keys, values, and items == annoying :)
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What about PEP 299?
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 somemodule.py`. > > You can do "python -x somemodule" as long as somemodule.py uses the if > __name__=='__main__' convention. What does your proposal add? FWIW, you can already (Python 2.4) do something like: --- x.py - import sys if __name__ == __main__: del sys.argv[0] # Get rid of reference to ourselves mod_name = sys.argv[0] # First arg is now module to be run mod = __import__(mod_name) # Run the top level module code main = mod.__main__ # Grab the main function sys.modules["__main__"] = mod # Make that module the __main__ one try: sys.argv[0] = mod.__file__ # Try to set argv[0] properly except AttributeError: pass sys.exit(main(*sys.argv)) # Run the function - Put that in site-packages and "python -mx somemodule" will do exactly as Charles describes. Getting it to work with a filename instead of a module name would be a bit trickier, but not a lot. However, I think PEP 299 is mainly a holdover from C/C++/Java where the top level of a module is a play area for the compiler that the runtime never really gets to see. I know I found PEP 299 appealing when I first seriously started using Python, but the appeal faded over time as I got used to the idea of being able to have control logic at the top level of a module (to the point where the idea is now thoroughly *un*appealing). PEP 299's other 'use case' (trying to run another program's main function from within the current program) seems like a recipe for disaster - far better to use the subprocess module instead (since, strangely enough, application initialisation code has this tendency to assume it has sole control of the interpreter). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
Barry, go ahead with PySet_Clear(). Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
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 list. Both of these are routine occurrences for my class use cases. We have a couple of instances where we use multiple decorators, and even a case where one of them takes an argument. It's not too bad. I agree with your comments about class decorator readability though. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
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 segfault. My worry is
about returning a different result than before. Actually I believe the
problem is not specific to C extensions. Here are some typical behavior
changes that could be observed in pure Python already:
class X(object):
def __radd__(self, other):
return 42
def __iter__(self):
return iter("xyz")
def __rmul__(self, other):
return 42
def __index__(self):
return 5
t = []
t += X()
print t# current: 42 new: ['x', 'y', 'z']
print [1] * X()# current: 42 new: [1, 1, 1, 1, 1]
Another visible difference is that the __add__/__iadd__/__mul__/__imul__
methods of lists, tuples, strings etc., will return NotImplemented
instead of raising the TypeError themselves. This could impact user
subclasses of these built-in types trying to override and call the super
methods, not expecting a NotImplemented result (a reason why
NotImplemented should have been an exception in the first place IMHO).
(A different bug I found is that [1].__mul__(X()) with an __index__able
class X currently raises TypeError, even though [1]*X() works just
fine.)
This seems to be it on the incompatibility side. I'd vote for the
change anyway because the language specs -- as well as PyPy and probably
all Python implementations other than CPython -- don't have this
double-slot inconsistency and already show the "new" behavior. For what
it's worth no CPython test breaks on top of PyPy because of this.
If this change is accepted I'll submit a patch for 2.5.
A bientot,
Armin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
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 was a crack at a particular position he's taking on a particular issue. What I intended (but may have failed) to convey was: "Raymond's a clever and sensible chap, and this is a very weird position for a clever and sensible person to be taking: must be the drugs." And, just in case it's still not clear, I wasn't in fact suggesting that Raymond *is* on drugs either. 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? -- g ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 least for the maintenance releases. The email packages in the sandbox svn:external the library from the appropriate Python branch. The rest of the sandbox serves as a repository for all the chrome around releases, e.g. generated docs, setup.py, etc. For email 4.0 I did things a little different, treating it more like a dev branch until it was stable enough to merge back into the trunk (which reminds me, I have to twiddle the sandbox to svn:external it again). That works well for email, but you may want to do something differently. In general though, I think the sandbox is a great place to develop and release standalone packages that are also integrated with Python. So if you wanted to do something similar for pysqlite I'd be totally fine with that. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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.sqlite'. +1 on 'database' as the top-level package name. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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' rather than 'db.sqlite'. > > +1 on 'database' as the top-level package name. I think short names are more more consistent with the existing naming in the standard library. +1 on db.sqlite from me. 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. -- Gerhard ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
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 particular kind of object, or that it >implements or provides a particular interface. We have different functions>that get used for this purpose in classes that are executed within the body>of the class. There's some merit to being able to use a single set of >functions in both cases, since the use cases are the same. I'm not sure I'd>want to change the existing pattern, though, since it's already so widespread>within the Zope 3 codebase (including 3rd-party components). 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 here, blah blah blah """ Yeah, but in the first case implements(IFoo) has to do dirty hacks involving sys.getframe(), so you win in once place but lose in the other one. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 database.oracle there's no need to group the SQL databases. -- Michael Chermside ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 much better than nested there is no need to create a "database" namespace. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 that XML is *always* referred to that way in texts except for an initial expansion so people know what it stands for, whereas database is only abbreviated in limited circumstances. In addition, three characters is more visible than two. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Look, it's your affair if you want to play with five people, but don't go calling it doubles." --John Cleese anticipates Usenet ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
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 >> >>then a will be asked "Please add yourself to b", and a >>will say "Okay, I know how to do that!" and promptly >>concatenate itself with b. > > > No: there is a difference between + and += for lists. You can only > concatenate exactly a list to a list. Indeed: > >>>> [].__add__((2, 3)) >TypeError: can only concatenate list (not "tuple") to list > > By contrast, list += is like extend() and accepts any iterable. > 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. 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. There's not much to be done about it short of adding __iadd__s everywhere, which is probably brittle and unfriendly. And, admittedly this is a corner case that's very rarely going to cause trouble. 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. Similarly for other inplace operations, of course. I'm not certain that all of the consequences of this change would be benign, but it's something to consider. > I'll try harder to see if there is a reasonable example whose behavior > would change... > Regards, Tim Hochberg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assignedabug/patch
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 enough. I'm completely fail to see why a Trac server shouldn't scale up at least as well as the SF-hosted Python tracker... (I mean, we're talking about one project, not 116,757 ...) > Of course, if there are only a few bits missing, instead of paying someone > to operate a complicated tracker, perhaps the money could be used to pay > someone to improve Trac... I cannot find the message right now, but I'm quite sure that someone recently suggested that the right way to try out a new tracker was to use it for the Python 3000 activity. my suggestion is to ask the python-hosting folks if they're willing to set up a free pyk3 account: http://www.python-hosting.com/freetrac 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 funds to pay for suitably large commercial account. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assignedabug/patch
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 funds to pay for suitably large commercial account. 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. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assignedabug/patch
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 system (which would be the >> most important subsystem for us) scales up well enough. > >I'm completely fail to see why a Trac server shouldn't scale up at least as >well as the SF-hosted Python tracker... (I mean, we're talking about one >project, not 116,757 ...) One reason might be the lack of paging for tickets. Viewing ~600 tickets at once (approximately the number of open tickets in Twisted's tracker) serves up a 2MB page. How many open tickets does Python have? :) Another reason is that the currently released version hemorrhage memory pretty badly (sometimes ~30MB for a single HTTP request). This is better in [EMAIL PROTECTED], but I don't think it's entirely resolved yet. Not that I am suggesting these and the other problems like them are unfixable, but someone will have to fix them, and whoever is going to have to admin the installation should be aware that there will be some issues. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assignedabug/patch
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 solutions for python ? I think there are good python solutions for a bug tracker and we should prefer them. -- bye by Wolfgang ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
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. :-)
Interesting. I might have to rename some of my decorators to read well
that way, though. I'll play around with the idea a bit.
Of course, one of my use cases for class-level declarations is to work
around the fact that decorators can't be applied to arbitrary attributes of
a class, only to methods. Hm. Let me see:
class SomeThing:
"""Some docs"""
@class security.permissions(
foo = security.Anybody,
bar = myapp.User,
...
)
class SomeCommand:
"""usage: some_command [-v|-q] [-f FILENAME] ..."""
@class options.accept(
verbose = [
options.Set('-v', '--verbose', value=True, help="Be loud"),
options.Set('-q', '--quiet', value=False, help="Be quiet")
],
filename = [
options.Set('-f', '--file', type=str, metavar="FILENAME")
]
)
Not bad. Not bad at all.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 the result will be required, but it might be a good way to get the mechanical parts of the translation done. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 works with existing Python versions. And the 'pkg_resources' module, slated for 2.5a2 inclusion, offers another way, that also works with modules supplied in eggs. So this bit is going to be more of a policy decision (pkgutil vs. pkg_resources) rather than a technical problem per se. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
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 actually clarified the point I > was > trying to make originally. > > My point wasn't that I desparately need @-syntax for class decorators (I > don't), or see it as inherantly superior in some way. It's much simpler than > that: I just want to be able to use the same syntax for a group of use cases > regardless of whether the target is a function or a class. > > This fits into the nice-to-have category for me, since the use case can be > the > same regardless of whether I'm decorating a class or a function. (I will > note that when this use case applies to a function, it's usually a > module-level function I'm decorating rather than a method.) Agreed, let's not have the decorator syntax argument all over again. Once someone knows how a function decorator works they should be able to guess how a class decorator works. In my old patch[1] the grammar production for decorators was: decorated_thing: decorators (funcdef|classdef) Which makes sense, once you know how to decorate one thing you know how to decorate all things. -jackdied [1] http://python.org/sf/1007991 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Iterators for dict keys, values, and items == annoying :)
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 wondering what "far less convenient" means. Is it simply the 4 extra key presses? I find the iter* variants to be a great solution. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
> 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-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 in mind? os? xml? email? Let's not get excited over names here. I say: let the RM or the BDFL, whoever feels responsible to pronounce whether PySQLite actually gets in, decide which name it will have. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 > these things sounded like API changes which may be more problematic > once in the core as we may have stricter rules on backwards > compatibility. > > We also have to convert the doc from ReST to latex. None of these are > show stoppers, but it adds to the amount of work we need to do before > release. And there's already more work than we can handle. This should all depend on volunteers being willing to contribute. If Gerhard wants to do this all on his own, and finds the time - that would be fine with me. Also, if others are willing to help, that could work (e.g. conversion of the documentation could be done by a different contributor). However, the release schedule for 2.5 should not change because of that. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 MS > VS2003, but I don't have enough experience with the Python build process > to not make stupid mistakes here. I could create the VC project file if desired. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assignedabug/patch
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 used, if not it's better to use something that works well regardless of what it's written in. (Not that I qualify to have an opinion. I don't have time to contribute to Python, other than with snarky emails.) -- Benji York ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
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 surprising notion, and I don't think it should be done. Either there is a need for the API, in which case it should be added, or there isn't (and the user is mistaken requesting it), then it shouldn't be added. 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 believe Barry's testimony. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What about PEP 299?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
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 expect this, right?
>
> Yes, I don't think C extensions are going to segfault. My worry is
> about returning a different result than before. Actually I believe the
> problem is not specific to C extensions. Here are some typical behavior
> changes that could be observed in pure Python already:
>
> class X(object):
> def __radd__(self, other):
> return 42
> def __iter__(self):
> return iter("xyz")
> def __rmul__(self, other):
> return 42
> def __index__(self):
> return 5
>
> t = []
> t += X()
> print t# current: 42 new: ['x', 'y', 'z']
> print [1] * X()# current: 42 new: [1, 1, 1, 1, 1]
>
> Another visible difference is that the __add__/__iadd__/__mul__/__imul__
> methods of lists, tuples, strings etc., will return NotImplemented
> instead of raising the TypeError themselves. This could impact user
> subclasses of these built-in types trying to override and call the super
> methods, not expecting a NotImplemented result (a reason why
> NotImplemented should have been an exception in the first place IMHO).
>
> (A different bug I found is that [1].__mul__(X()) with an __index__able
> class X currently raises TypeError, even though [1]*X() works just
> fine.)
>
> This seems to be it on the incompatibility side. I'd vote for the
> change anyway because the language specs -- as well as PyPy and probably
> all Python implementations other than CPython -- don't have this
> double-slot inconsistency and already show the "new" behavior. For what
> it's worth no CPython test breaks on top of PyPy because of this.
>
> If this change is accepted I'll submit a patch for 2.5.
I trust you in these matters. Go for it.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
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. Why not? It doesn't really differ much from the following example IMO: >>> x = 3 >>> x += 0.5 >>> x 3.5 >>> -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
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 here, blah blah blah > """ But the former also smells more of magic. A function putting a magic variable into the scope in which it is called isn't exactly elegant use of Python. You've probably read too much Zope code to be sensitive to this argument; but to me it still grates. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assignedabug/patch
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 differing opinions. > > 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. 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. In this case I think the criteria should be saving volunteer sysadmin time in maintenance, conveniece for users, and convenience in developer time (not necessarily in that order). I don't know any of the suggested systems well enough to know how they score, so I don't want to side any particular proposal; but I think we should not base our argument on "it's written in competing language X". Beware NIH. Also, we're supposed to be friendly with Java, as we have a major product in that arena. What if Java folks were to reject a Python solution because it's not written in Python? Wouldn't we be upset about the parochialism? 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What about PEP 299?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 setuptools docs. I'm sure that > editing the result will be required, but it might be a good way to get the > mechanical parts of the translation done. > I am currently using a somewhat hacked version of Greg Ward's mkpydoc script to convert the ctypes tutorial into libctypes.tex. So far it works great, except that I'm having problems converting a table. I'm in contact with someone from the docutils users list who has helped me with some TeX stuff. The hacked version of mkpydoc is here: http://cvs.sourceforge.net/viewcvs.py/ctypes/ctypes/docs/manual/mkpydoc.py?rev=1.7&only_with_tag=HEAD&view=markup Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF whenassignedabug/patch
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 used as an argument if all else is > equal. since it's a lot easier to get Pythoneers to volunteer time to work on (develop, hack, keep running, create add-ons for) a solution written in Python, the criteria ought to be "the language choice is only irrelevant if there's no Python solution that's good enough". it's also a marketing thing; if the developers don't want to eat Python dogfood, why should anyone else do that ? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 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 have to go with "no" just to err on the side of safety. I have strong feelings about the language. Sometimes I have strong feelings about the library. This doesn't seem to be one of those cases though... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF whenassignedabug/patch
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 hundred years. Fair enough. I like "good enough" as a criterion; it's served me well in real life for many years, since it reduces the time I waste pondering decisions. Unlike language design issues, tool selection choices aren't forever. > > The language choice should only be used as an argument if all else is > > equal. > > since it's a lot easier to get Pythoneers to volunteer time to work on > (develop, hack, keep running, create add-ons for) a solution written in > Python, the criteria ought to be "the language choice is only irrelevant > if there's no Python solution that's good enough". > > it's also a marketing thing; if the developers don't want to eat Python > dogfood, why should anyone else do that ? Sure. There are plenty of reasons to prefer Python, making all else "not equal". I was just warning against knee-jerk parochialism, which I don't think will serve us well. There's Perl code in the Python source tree, and the only reason to get rid of it IMO should be if it no longer serves our purpose. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
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 believe Barry's testimony.
It doesn't seem to me that there really is a significant code
simplification, looking at the diff between Raymond's code examples.
@@ -7,2 +7 @@
-PyObject *key;
-Py_ssize_t pos = 0;
+PyObject *it, *key;
@@ -13 +12,5 @@
-while (set_next(so, &pos, &key)) {
+it = PyObject_GetIter(self);
+if (it == NULL)
+return -1;
+
+while ((key = PyIter_Next(it)) != NULL) {
@@ -14,0 +18 @@
+Py_DECREF(key);
@@ -16 +20,2 @@
-return -1;
+Py_DECREF(it);
+return -1;
@@ -19,0 +25,3 @@
+Py_DECREF(it);
+if (PyErr_Occurred())
+return -1;
James
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What about PEP 299?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 yes. > >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? Pro: * SQLite is really nice to have for writing simple applications with small data needs, especially client-side software. It's probably the best-of-breed open source embedded SQL DB right now. * So, having a wrapper would be a big "Batteries included" plus for Python 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 of I personally lean somewhat toward the con side because to me it's just as easy to "easy_install pysqlite" after the fact, or get it from the appropriate packager (RPM, Debian, whatever). However, we can't please everybody. If we go for more "batteries included", one group will complain about how much we have linked in and don't have proper system dependencies. If we go for "easy to install add-ons", the same people will gripe that it's the job of the packaging system to do those add-ons, and another group will chime in that they don't have or don't want the packaging system. So we might as well flip a coin. :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 pronouncement? I'd say yes. >> >>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? > > Pro: > > * SQLite is really nice to have for writing simple applications with small > data needs, especially client-side software. It's probably the > best-of-breed open source embedded SQL DB right now. > > * So, having a wrapper would be a big "Batteries included" plus for Python > > Con: > > * Competing Python wrappers exist Which aren't DBAPI compliant, and I think not nearly as popular. > * SQLite itself is updated frequently, let alone the wrappers That's a point. > * Build integration risks unknown, possible delay of 2.5? There could be an sqlite-integration branch. If it's ready for beta 1, it is merged then, if not, it is merged to trunk after 2.5 final happened. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 > have to go with "no" just to err on the side of safety. I have strong > feelings about the language. Sometimes I have strong feelings about > the library. This doesn't seem to be one of those cases though... Let me try to take both sides simultaneously: For: would add an SQL library to the standard distribution, and one that doesn't depend on additional infrastructure on the target machine (such as an existing database server); the author of that library is fine with including it in Python Against: Adds work-load on the release process, adding more libraries to the already-large list of new libraries for 2.5. Choice of naming things is ad-hoc, but gets cast in stone by the release; likewise, choice of specific SQL library might inhibit addition of different libraries later. I'm sure people will add to the list if they think I omitted important points. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 argument for me? Otherwise I'll > > have to go with "no" just to err on the side of safety. I > have strong > > feelings about the language. Sometimes I have strong feelings about > > the library. This doesn't seem to be one of those cases though... > > Let me try to take both sides simultaneously: > > For: would add an SQL library to the standard distribution, and one > that doesn't depend on additional infrastructure on the target machine > (such as an existing database server); the author of that library is > fine with including it in Python > > Against: Adds work-load on the release process, adding more libraries > to the already-large list of new libraries for 2.5. Choice of naming > things is ad-hoc, but gets cast in stone by the release; likewise, > choice of specific SQL library might inhibit addition of different > libraries later. More Against?: Explaining "database is locked" errors (due to SQLite's exposed multiple-readers/one-writer design) on a daily basis (FAQ entries notwithstanding). Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 ? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 an excellent choice for many kind of applications. it has no com- petition in this space. gerald's pysqlite binding is a second-generation implementation of the full DB-API (http://www.python.org/dev/peps/pep-0249/) for sqlite. 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
-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 small > data needs, especially client-side software. It's probably the > best-of-breed open source embedded SQL DB right now. > * So, having a wrapper would be a big "Batteries included" plus for Python That would be my arguments, too. > Con: > > * Competing Python wrappers exist There is really only one other relevant wrapper: APSW. It was purposefully designed to *not* use the DB-API 2.0 (though a similar one), and being a "thinner" wrapper of SQLite. It wraps a few more functions of the SQLite API, though less and less, because pysqlite is catching up here. While there might be arguments for a "thinner" wrapper, I think that pysqlite has the advantage of being DB-API compliant (even with most optional DB-API extensions) and thus offers a good way to prototype database apps with a smooth upgrade path to other, more powerful, databases. > * SQLite itself is updated frequently, let alone the wrappers SQLite being updated regularly is not really a problem, because we can link dynamically against SQLite. And we probably *should* do this on Windows, too, so users can replace a SQLite.DLL with an updated version if they wish to. > * Build integration risks unknown, possible delay of 2.5? > * Another external library to track and maybe have emergency updates of Emergency updates are only for security problems, right? I don't think this would apply to pysqlite. I don't think that would apply to SQLite either, but if it's conceivable, it's another argument for dynamic linking. - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEKvlzdIO4ozGCH14RAuLKAJ9BGnHz4Tym60xOGSwSuqXlqRaAdwCdFeqx +vo5eC0aBu4S2sttb/iZPOc= =bJKK -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
[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(). 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). Neither of these proposals are necessary. Both have safe, simple, workable alternatives. It is not my problem if those alternatives do not suit your tastes. A personal aversion to the abstract api is no reason to forgo safety or to interfere with future development of the module. Quality and flexibility considerations trump micro-optimizations and personal style biases. Most of the push has been predicated on being in a snit about the existing iterator API. However, in the course of writing itertools and other Python enchancements, I've had occassion to thoroughly exercise the iterator API and have not found it to be a problem in practice. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
> gerald's pysqlite binding sorry, gerhard. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Discussing the Great Library Reorganization
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 think we can take a queue from Java. I think we should have a root package, 'py', and then have subpackages within that. Those subpackages would group the existing modules that are not already in a nice package hierarchy. In other words, try to make it so that importing an actual module takes no more than three dots in the general case: ``from py.dev import pdb``, etc. I do think it is okay to put things without proper classification just under 'py' without being in a subpackage. The three dots idea is not hard. We could, for instance, have a py.dist subpackage and have pkgutil and distutils under it. That will make the modules in distutils take four dots, but that's just life and I think within reason for something that is not used directly by a large number of people. I also have no issue taking certain names from existing modules and making them both a module directly (as in putting what exists in a module into __init__.py for the subpackage with the same name) on top of putting more modules in the subpackage. The issue I see with this, though, is people doing something like ``from py import pickle; pickle.pickletools.dis()``, not realizing they need to import pickletools directly instead of getting to it through py.pickle . I don't want to spark a subpackage grouping discussion yet since we should decide on a general strategy of how we want the basic stdlib organized. I also don't want to argue over module renaming directly since that can be based on what subpackages there might be. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Discussing the Great Library Reorganization
-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 Library Reorganization that has been discussed > for eons. [...] Wouldn't the newly founded python-3000 mailing list be the perfect place for such major changes? - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEKwBWdIO4ozGCH14RAnIkAJ9L/m8J4aiIisJKVimIv15mvSQApgCgnvP4 H/aV/ZuLs0DLScvnyrfsGPo= =Dm7c -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 these con arguments go for bsddb, too, and without sounding too negative about bsddb, I believe SQLite is a *much* better solution than BerkeleyDB, for roughly the same problem space. The same goes for pysqlite vs. bsddb. IMNSHO, SQLite and pysqlite are much easier to use correctly than BerkelyDB and bsddb, for simple and complex tasks. I may be biased against bsddb because I spent too much time hunting refleaks in it, but I'm not biased in favour of SQLite -- I'm a PostgreSQL user myself. ;-P I personally lean somewhat toward the con side because to me it's just aseasy to "easy_install pysqlite" after the fact, or get it from the appropriate packager (RPM, Debian, whatever).Actually, I have no doubt that all the package managers will split the 'bundled' pysqlite (whatever the name will be) in a separate package, just like it's done for Tkinter and bsddb and most other stdlib modules with extra dependencies. Nevertheless, adding it to the standard library is probably a good thing. I would probably choose sqlite instead of shelve/anydbm/bsddb if it were part of the standard library, even though it's probably installed on all my machines anyway. I guess it's a psych thing. As for people asking about deadlocks, well, I much rather explain about sqlite deadlocks than about BerkelyDB transactions.-- Thomas Wouters <[EMAIL PROTECTED] >Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Discussing the Great Library Reorganization
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 stdlub. Perhaps it's time to start > > discussing the Great Library Reorganization that has been discussed > > for eons. [...] > > 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 backwards-compatible by having old names fully import the new name directly (``from py.dev.pdb import *``), especially if we put everything under the 'py' package and thus remove any possible name clashing with the existing arrangement. So I posted to python-dev since I think we could do it in 2.6 and then remove a ton of old modules we don't want anymore in 3000. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 would be a big "Batteries included" plus Phillip> for Python Phillip> Con: Phillip> * Competing Python wrappers exist Phillip> * SQLite itself is updated frequently, let alone the wrappers Phillip> * Build integration risks unknown, possible delay of 2.5? Phillip> * Another external library to track and maybe have emergency Phillip> updates of 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. Of course, that can and does happen today. Including pysqlite with Python just means it will happen more frequently. Phillip> I personally lean somewhat toward the con side because to me Phillip> it's just as easy to "easy_install pysqlite" after the fact, or Phillip> get it from the appropriate packager (RPM, Debian, whatever). Is it not possible to distribute an empty db package which is then populated with various database eggs (or other similar installation things)? Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Discussing the Great Library Reorganization
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 nice if there were a central repository of "blessed" extensions to the standard library which could be selectively loaded when a new version of Python is installed. There'd also need to be a tool for checking the extensions for new versions and upgrading since they would most likely not be maintained in lockstep with Python and its standard library. On Wed, 29 Mar 2006, 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 Library Reorganization that has been discussed > for eons. > -- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
[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 more weird. is there *any* part of the standard Python distribution that cannot be applied to problems for which it is ill-suited? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Discussing the Great Library Reorganization
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 backwards-compatible by > having old names fully import the new name directly (``from py.dev.pdb > import *``) hmm. I'm starting to think that the 3000 project may cause the core 2.X development to derail, even before 2.5 is out... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.4.3, final.
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 squished in this release, including a number found by the Coverity Scan project. Assuming no major bugs pop up, the next release of Python will be Python 2.5 (alpha 1), with a final 2.4.4 release of Python shortly after the final version of Python 2.5. The release plan for Python 2.5 is documented in PEP-0356. For more information on Python 2.4.3, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.4.3/ Highlights of this new release include: - Bug fixes. According to the release notes, at least 50 have been fixed. - A small number of bugs, regressions and reference leaks have been fixed since Python 2.4.3 release candidate 1. See NEWS.txt for more. Highlights of the previous major Python release (2.4) are available from the Python 2.4 page, at http://www.python.org/2.4/highlights.html Enjoy this new release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgpycme1bl6TX.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
> 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 "database" would be wrong. I might change my mind if all stdlib packages were under some toplevel package, like "stdlib". Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 see pysqlite in 2.5 is that it follows the standard DB-API. People can start off using it, then look at switching to a larger database if their application needs grow. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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-like "namespace packages" in Python, the answer is yes. The stdlib module "pkgutil" supports this for regular filesystem packages, and the "pkg_resources" module in setuptools extends this support to zipfiles and eggs. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 to me, as well. I'd love to see a DB-API compliant module, and an embedded SQL database, in the core. I don't believe that there's anything comparable to (py)sqlite on that score. And as Anthony pointed out, it provides a nice upgrade path to "bigger" SQL/DB-API solutions. +1 from me. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Discussing the Great Library Reorganization
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 independently and installed independently. > It would be nice if there were a central repository of "blessed" > extensions to the standard library which could be selectively loaded when > a new version of Python is installed. There'd also need to be a tool for > checking the extensions for new versions and upgrading since they would > most likely not be maintained in lockstep with Python and its standard > library. I think we should discuss this, but not necessarily here. Whether we want a blessed Cheeseshop section and have anything from there be automatically downloaded and installed as needed for the installed interpreter for things that we feel are important (ala pysqlite) but not necessarily in the core distribution should be discussed. But since I don't distribute individual modules often enough I am not in a position to lead that discussion. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
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) Someone is going to object that the evaluation time and environment of the decorator is screwy. But I don't care. :-) Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 this work (for alpha2), Martin's willing to do the Windows build project - so I'm going to say "it's going to be in 2.5". I've really not seen any arguments that convince me otherwise. Martin: > Against: Adds work-load on the release process, adding more > libraries to the already-large list of new libraries for 2.5. Choice > of naming things is ad-hoc, but gets cast in stone by the release; > likewise, choice of specific SQL library might inhibit addition of > different libraries later. I'm happy to do the work (and you've said you're ok to do the windows part). All naming in the stdlib is adhoc by it's nature. We choose a name, and then that's it's name. I'm pretty happy with either 'db.sqlite' or 'database.sqlite', really. I don't think there's an alternative implementation of pysqlite bindings that could be considered for the stdlib. If an alternative to sqlite comes out some time, I don't have a problem with adding it. Phillip: > * Competing Python wrappers exist There's one - and it's not DB-API compliant. I know a lot of people who use the pysqlite wrapper, I've not come across anything that uses APSW. > * SQLite itself is updated frequently, let alone the wrappers > * Another external library to track and maybe have emergency updates > of Only an issue on platforms where we're not using the system-installed version. While sqlite gets new versions, very very few of these are security-related (I can't recall one lately) > * Build integration risks unknown, possible delay of 2.5? If it's going to cause a delay, it slips until 2.6. Easy. :) Skip: > 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. Of course, that can and does happen today. > Including pysqlite with Python just means it will happen more > frequently. Er - what? Right now, people are far more likely to use bsddb or anydbm for an inappropriate problem space. Adding a _better_ solution makes this better, not worse. I mean, adding ElementTree could also mean people will use XML in more places that are inappropriate, too, but I didn't see that raised as a problem. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Discussing the Great Library Reorganization
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 'std' do as well for the top level, or should we use "python" for the python-coded versions? -- -- Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
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 biguglydecorator(longconvolutedarglist) -1; there should be only one obvious way to do it. Plus, @class is a noun and reads like it's saying something about the class; @def doesn't. It's too "verby". :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 Language abbreviate it "xml". People who are familiar with electronic mail abbreviate it "email". And people who are familiar with the concept of a database abbreviate it "db". Why are two right for the stdlib (sorry, "standard library" :), and the other wrong? Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Discussing the Great Library Reorganization
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 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 path? Doesn't the absolute/relative import PEP solve this problem? And what does 'from py import *' do, anyway? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 issues. > > Ok - well, I'm willing to work with Gerhard to do this work (for > alpha2), Martin's willing to do the Windows build project - so I'm > going to say "it's going to be in 2.5". I've really not seen any > arguments that convince me otherwise. Sounds like an excellent decision. Having it standard in the Windows build is actually going to be a big plus (though not for me personally :-). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Discussing the Great Library Reorganization
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 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 path? Yes, it's to make it obvious the module came from the stdlib instead of another package. > Doesn't the > absolute/relative import PEP solve this problem? > Basically, but I think it wouldn't hurt to have a specific package name for the stdlib for in-code documenting instead of thinking that perhaps someone just stuck a module directly on sys.path . > And what does 'from py import *' do, anyway? Not much. =) It would import the top-level of a bunch of subpackages which will most likely not get you to a module, class, or function and thus couldn't be used to resolve to anything. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 abbreviate it "xml".
> People who are familiar with electronic mail abbreviate it "email". And
> people who are familiar with the concept of a database abbreviate it "db".
> Why are two right for the stdlib (sorry, "standard library" :), and the other
> wrong?
Wow, what a world of black-and-white people we've got :-).
Here's what I was thinking:
"db" and "em" are too short to be useful context-free abbreviations,
because there's too much chance of either conflicting with variable
names in existing programs, or being confused with some other meaning
for those two letters.
"email" and "xml", on the other hand, have enough real-world emphasis
to be suitable. "stdlib" might or might not be OK ("python_stdlib"
might be better, or "pystdlib"); "py" surely isn't.
Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] warnings in libffi
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 build/temp.darwin-8.5.0-Power_Macintosh-2.5/libffi/include/ffi.h:273: warning: function declaration isn't a prototype /Users/drifty/Code/Trees/svn/python/trunk/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c:383: warning: function declaration isn't a prototype /Users/drifty/Code/Trees/svn/python/trunk/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c:384: warning: function declaration isn't a prototype /Users/drifty/Code/Trees/svn/python/trunk/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c:388: warning: function declaration isn't a prototype /Users/drifty/Code/Trees/svn/python/trunk/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c:389: warning: function declaration isn't a prototype /Users/drifty/Code/Trees/svn/python/trunk/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c:394: warning: function declaration isn't a prototype 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)? -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Discussing the Great Library Reorganization
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 normal search path? > > Yes, it's to make it obvious the module came from the stdlib > instead of another package. In that case, I don't see why this couldn't be added to import, rather than moving all the files around. > Basically, but I think it wouldn't hurt to have a specific package > name for the stdlib for in-code documenting instead of thinking > that perhaps someone just stuck a module directly on sys.path . I'm not convinced it buys us anything over just using the absolute import mechanism in the PEP. > > And what does 'from py import *' do, anyway? > > Not much. =) It would import the top-level of a bunch of > subpackages which will most likely not get you to a module, class, > or function and thus couldn't be used to resolve to anything. So you're saying that the toplevel of 'stdlib' wouldn't contain any real modules, but instead they'd be grouped under sub-packages? Good luck finding a home for everything... trying to categorise everything will be nearly impossible. And 'from stdlib.misc import foo' will make me very very unhappy. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Discussing the Great Library Reorganization
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 > > > that. > > > > org.python.stdlib, surely? > > > > 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 path? > > Yes, it's to make it obvious the module came from the stdlib instead > of another package. Dream on. The Java "standard" namespace is polluted with weirdnesses like "javax" (some kind of extensions) "org.xml", etc. > > Doesn't the > > absolute/relative import PEP solve this problem? > > Basically, but I think it wouldn't hurt to have a specific package > name for the stdlib for in-code documenting instead of thinking that > perhaps someone just stuck a module directly on sys.path . Actually it doesn't. > > And what does 'from py import *' do, anyway? > > Not much. =) It would import the top-level of a bunch of subpackages > which will most likely not get you to a module, class, or function and > thus couldn't be used to resolve to anything. I'd like to nip this discussion in the bud; it's just going to waste a lot of developers time. We need more people thinking seriously about the process and meta issues for Python 3000. (Yes, I know, I need to catch up with some threads myself. Hopefully next week when I'm no longer a single parent.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Discussing the Great Library Reorganization
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 path? Doesn't the > absolute/relative import PEP solve this problem? I don't think so. For instance, if I have a package called "db" in my application (which I import with absolute imports from other packages), I might have problems with the newly added "db.sqlite" package in Python 2.5. In fact, I guess my "db" will shadow the stdlib one, making it impossible to access. An unique prefix for stdlib would solve this. Giovanni Bajo ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
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 a += b is equivalent to a = a + b when a can't be modified in-place. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
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:
> >
> > @implements(IFoo)
> > class Foo:
> > """Docstring here, blah blah blah
> > """
>
>But the former also smells more of magic.
My comment above was only about readable *placement* of the decorators, not
the actual syntax. Many approaches to the actual syntax in the body are
possible.
For example, what did you think of Fred Drakes's "@class" proposal? To
specify it formally, one could say that this:
@class EXPR
in a class scope would expand to the equivalent of:
locals().setdefault('__decorators__',[]).append(EXPR)
and is a syntax error if placed anywhere else. That, combined with support
for processing __decorators__ at class creation time, would fulfill the
desired semantics without any implicit "magic".
(The locals() part could of course be implemented in bytecode as
LOAD_LOCALS, since class scopes implement their locals as a
dictionary. That would avoid the need for adding any new bytecodes, since
this isn't a performance-sensitive feature.)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
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 why not just go ahead and do that now? If you know that's what you want eventually, why wait? From my perspective, adding a NULL at the end of the argument list wouldn't be that big of a deal. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
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 > > variable length argument list instead of a single argument). > > So why not just go ahead and do that now? If you know that's what you > want eventually, why wait? From my perspective, adding a NULL at the > end of the argument list wouldn't be that big of a deal. BTW, I'm willing to do the work on this. I'm already going to update my patch anyway to reflect our current decisions, so I'm happy to do this while I'm at it. I'll try to get a new patch posted in a day or so. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
> Charles Cabazon writes: Whoops! Should be "Cazabon". Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 build issues. > > Agreed. As a SQL user, it feels like a no-brainer to me, as well. I'd > love to see a DB-API compliant module, and an embedded SQL database, > in the core. I don't believe that there's anything comparable to > (py)sqlite on that score. > > And as Anthony pointed out, it provides a nice upgrade path to > "bigger" SQL/DB-API solutions. > > +1 from me. +1 here, too; just as /f said, the only real issue is time (as in, is it too late to get such a package into 2.5), but with the volunteering I've seen that should be feasible. I just hope we get a BDFL +1 soon so I can add the good news to the 2nd ed of "Python in a Nutshell", which is due to go "printers-wards" about 8-9 days from now (in order to be ready for OSCON -- the times from final text version to paper are NOT brief:-). Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
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 blah
> > > """
> > > implements(IFoo)
> > >
> > > is easier to read than:
> > >
> > > @implements(IFoo)
> > > class Foo:
> > > """Docstring here, blah blah blah
> > > """
> >
> >But the former also smells more of magic.
>
> My comment above was only about readable *placement* of the decorators, not
> the actual syntax. Many approaches to the actual syntax in the body are
> possible.
>
> For example, what did you think of Fred Drakes's "@class" proposal? To
> specify it formally, one could say that this:
>
> @class EXPR
>
> in a class scope would expand to the equivalent of:
>
> locals().setdefault('__decorators__',[]).append(EXPR)
>
> and is a syntax error if placed anywhere else. That, combined with support
> for processing __decorators__ at class creation time, would fulfill the
> desired semantics without any implicit "magic".
>
A function decorator takes a function as an argument and returns something
(probably a function and maybe even the very same function).
This is exactly what class decorators should do or we should call them
something else and give them a distinct syntax.
A function decorator is there to replace code like:
def myfunc(a, b, c):
# half a screen of code
myfunc = mangle(myfunc)
Likewise class decorators would save me from typing
class MyClass:
# many functions taking half a screen of code each
register(MyClass, db_id=20)
I used to do this with metaclasses but stopped because it requires making
'db_id' a member of the class which is magically noticed by a metaclass
two files away. 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.
Yuck.
If you want to do lots of Zopeish stuff mostly inside the class write
a decorator that looks for it in the class body.
@zope.find_magic_in_attr('mymagic')
class MyClass:
mymagic = [] # some long hairy thing
Talking about something other than a decorator or proposing all new
syntax is just going to get this pronounced out of existence.
If-I-wanted-zope-I'd-use-zope-ly,
-jackdied
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
>> 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 and more weird. Fredrik> is there *any* part of the standard Python distribution that Fredrik> cannot be applied to problems for which it is ill-suited? 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 "polluting" the production database, so the folks who wanted it went the SQLite/pysqlite route. They were immediately bitten by the multiple reader/single writer limitation and they tried to cram too much data into it, so performance further sucked. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
>> 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. That suggests other database interface modules like db.mysql, db.postgresql, db.sybase, etc. Given that we probably won't include all those as standard modules, we should make it easy for someone to install one or more of those modules via normal external mechanisms and have them appear seamlessly to the Python programmer. Then I begin to wonder why bother with db.sqlite at all. Why not just create an empty db package that does the pkgutil or pkg_resources dance and let people install all N database interfaces instead of just N-1? Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Discussing the Great Library Reorganization
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 Brett> has been discussed for eons. I think this belongs on the py3k list. Stdlib reorganization should be done with Py3k in mind, then backported to 2.x if deemed worthwhile and doable. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
