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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 ? ;-) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Iterators for dict keys, values, and items == annoying :)
Nick Coghlan wrote: a message to the wrong list Darn, I'd hoped I'd caught that in time :( Sorry folks. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
Barry, go ahead with PySet_Clear(). Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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'msure Phillip is familiar with these).They're used with functions toindicate that the function adapts a particular kind of object, or that it implements or provides a particular interface.We have different functionsthat get used for this purpose in classes that are executed within the bodyof 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'dwant to change the existing pattern, though, since it's already so widespreadwithin 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
gerald's pysqlite binding sorry, gerhard. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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... /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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? wink 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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? wink 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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? wink 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
Charles Cabazon writes: Whoops! Should be Cazabon. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
Anthony All naming in the stdlib is adhoc by it's nature. We choose a Anthony name, and then that's it's name. I'm pretty happy with either Anthony 'db.sqlite' or 'database.sqlite', really. Let's slow down here. If we are really going to start putting together a package infrastructure shouldn't it be done in the context of Brett's great stdlib restructuring PEP? If everything included in the stdlib is under some core package (core, stdlib, py, etc), that suggests that a package containing database wrappers would be named something like stdlib.db or py.database. The existence of a stdlib package certainly isn't a given. Still, let's assume for the moment that's how things fall out and we deliver pysqlite in the stdlib as stdlib.db.sqlite. If I want to install Object Craft's Sybase wrapper the logical place for it seems like stdlib.db.sybase. But that's not right because the Sybase module's not part of the stdlib. Okay, it belongs in site.db.sybase. But now we have two different db packages and the programmer has to care about stdlib vs external. (Maybe that's okay.) I'm sure there are a number of different workable solutions, but shouldn't they be considered before rather arbitrarily deciding that pysqlite belongs in db.sqlite or database.sqlite? If you're not willing to resolve the future naming scheme for 3.x or 2.6 at this point I see no reason start adding any package hierarchy(ies). Just toss it in as the sqlite module (no packaging) and be done with it. Don't start carving up the package namespace without considering the bigger picture. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Name for python package repository
I just thought of a possible name for the Python package repository. We could call it the PIPE - Python Index of Packages and Extensions. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
At 08:00 PM 3/29/2006 -0500, Jack Diederich wrote: A function decorator takes a function as an argument and returns something (probably a function and maybe even the very same function). So would class decorators. This is exactly what class decorators should do or we should call them something else and give them a distinct syntax. Yep. 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) Yep. Talking about something other than a decorator You lost me there. Nobody's argued (AFAIK) for class decorators being anything other than single-argument functions that take a class as input and return a class as output. or proposing all new syntax is just going to get this pronounced out of existence. Which wouldn't be a bad thing, IMO. There's no point in adding them if they're not an actual improvement over what we can do now. Comments about the hackishness of the implementation used by Zope and PEAK are also off-base; nobody proposed that everyone should go off and implement their own such hacks! Meanwhile, inclusion of such a facility in the stdlib isn't without precedent; there are IIRC at least *6* sys._getframe hacks in the stdlib already. Nothing stops us from adding a 'decorate_class' function to the stdlib that's used like this, for example: class MyClass: decorate_class( register(db_id=20), implements(IFoo), ... ) or to just make the class machinery interpret a __decorators__ attribute (a variant on an old suggestion of Guido's): class MyClass: __decorators__ = [register(db_id=20), implements(IFoo)] The only *implementation* reason to give this special syntax, IIUC, is to allow implementations like Jython and IronPython and Pyrex to statically recognize certain decorators at compile-time. There are of course also non-implementation reasons to have class decorator syntax (such as EIBTI), and I agree with that. But readability also counts, and the readability of @decorators on the outside of a class tends to suck as the number of decorators and arguments increases. What's more, I haven't seen anybody posting any counterexamples to show that it doesn't suck for common use cases. Indeed, at the moment I don't even recall seeing any examples of class decorators being used without arguments! I also suspect that any actual Jython/IronPython examples are likely to be at least as verbose as Zope and PEAK's, and probably more likely to include multiple decorators. (Depending on how Java annotations and .Net attribs would be translated to decorators.) So, I'm personally not in favor of adding class decorators with a syntax that blindly imitates that of function decorators, without a proper examination of the use cases. This is precisely the argument that Guido used to veto class decorators in 2.4, and nothing about the issue has changed since then, except for the subject being reopened to consideration. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
Bill Janssen wrote: db and em are too short to be useful context-free abbreviations, There's a big difference between db and em: db is an extremely well-known abbreviation, whereas em isn't. At the top level of a reorganised package namespace, I don't think it would be out of place to reserve db for database stuff. It can always be renamed on import if it happens to conflict with anything in code, and I wouldn't object to not being able to have my own top-level package called db. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
Greg There's a big difference between db and em: db is an Greg extremely well-known abbreviation, whereas em isn't. Unless you're a typesetter or a TeX hound... :-) Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
Phillip J. Eby wrote: My comment above was only about readable *placement* of the decorators, not the actual syntax. The placement is part of the syntax... -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
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). Would that really buy you anything much over just making multiple PySet_Update() calls? Is it just syntactic sugar, or is there some optimisation you can do with multiple updates presented all at once? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
[EMAIL PROTECTED] wrote: The powers-that-be didn't want to support another database server (we already have Sybase) and didn't want our group's experimental data polluting the production database, so the folks who wanted it went the SQLite/pysqlite route. They were immediately bitten by the multiple reader/single writer limitation and they tried to cram too much data into it, so performance further sucked. Firebird could be a solution to this. It can be used in a mode that doesn't need a server, and it has no trouble at all with concurrency or large amounts of data that I know of. In fact, a Firebird interface might be an alternative worth considering for the library. It would have most of the advantages of SQLite without these disadvantages. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
[EMAIL PROTECTED] wrote: If I want to install Object Craft's Sybase wrapper the logical place for it seems like stdlib.db.sybase. But that's not right because the Sybase module's not part of the stdlib. Okay, it belongs in site.db.sybase. But now we have two different db packages and the programmer has to care about stdlib vs external. (Maybe that's okay.) This seems to be an instance of the general problem of trying to fit a multidimensional classification into a hierarchical structure. Database systems solved this long ago by ditching the hierarchy completely and going relational. Maybe a single dotted hierarchy of package names is too restrictive? Should we be able to import things by specifying attributes instead of a pathname? import db where db.stdlib == True and db.language == SQL \ and db.interface == DBAPI2.0 ?-) -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
On Wednesday 29 March 2006 21:55, Greg Ewing wrote: import db where db.stdlib == True and db.language == SQL \ and db.interface == DBAPI2.0 While we're at it, we could spell import select. :-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
On Thursday 30 March 2006 12:07, [EMAIL PROTECTED] wrote: To many people SQL in the name implies big databases. I know from personal experience at work. The powers-that-be didn't want to support another database server (we already have Sybase) and didn't want our group's experimental data 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. And people trying to build production systems on SimpleHTTPServer, SimpleXMLRPCServer, smptd, or dumbdbm will also find their performance sucks. What's your point? Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
Phillip J. Eby wrote: the readability of @decorators on the outside of a class tends to suck as the number of decorators and arguments increases. So do decorators outside a function. What's more, I haven't seen anybody posting any counterexamples to show that it doesn't suck for common use cases. Indeed, at the moment I don't even recall seeing any examples of class decorators being used without arguments! Well, here's how my use case would look if I had class decorators: @IOClass class MyClass: ... Does that count? My decorator wouldn't need any arguments, because it looks inside the class for all the information it needs. [1] That's actually a general solution to Phillip's concern: the decorator can always look for attributes in the class (or the class's __dict__ if you don't want them inherited) for large amounts of information that wouldn't comfortably fit up the top. That's an extra degree of freedom that we don't have with functions. - - - - - [1] Actually I would probably give it one optional argument, the name to register under if different from the class name. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
On Thursday 30 March 2006 12:15, [EMAIL PROTECTED] wrote: Someone was throwing around names like db.sqlite as the place to install pysqlite. Dunno who originally suggested it, but the theory was that there's some issue with toplevel library namespace pollution. I'm not too stressed out one way or the other - but starting off with 'db.sqlite' (and then maybe moving/aliasing db.bsddb c at a future point) doesn't seem like a bad idea. 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? The same could be said of vast amounts of the standard library. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
[EMAIL PROTECTED] wrote: Greg There's a big difference between db and em: db is an Greg extremely well-known abbreviation, whereas em isn't. Unless you're a typesetter or a TeX hound... :-) Good point! Still, the fact remains that it's not a well-known abbreviation for *email*. :-) -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
