Re: [Python-Dev] I'm not getting email from SF whenassignedabug/patch
On 3/29/06, Fredrik Lundh [EMAIL PROTECTED] wrote: Neal Norwitz wrote: I'm in favor of having Atlassian setup a system to be used for 3k. It would be completely experimental and could be completely thrown away which should be made clear to Atlassian if we were to do this. I would use the system for evaluation. so what's the advantage of a freely hosted Atlassian setup compared to a freely hosted Trac setup ? Someone else's time to setup and maintain it. In particular, it won't take any time away from any python developer. Plus it's just a chance for me to learn. from what I can tell, no big contemporary Python project use Atlassian. they all use Trac. there are thousands of Python developers out there that are used to working with Trac. If someone setups and maintains an instance of Trac, I'd use that too. I suppose I could use Roundup on python.org, but I don't know if it's working. I've used Roundup before, but it was an old version and obviously not tailored to python's setup. Like I said, I won't be prepared to use any new tracker for some time, at least a couple of weeks. If people want to setup systems for me to test out, I'm willing to be a guinea pig. The only thing I really care about is what makes my life the easiest. 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] building sql queries in python
Getting off on a tangent here, but I would actually like some decent way of writing SQL queries in Python -- not for importing, but for database access. Constructing bits of SQL out of character strings sucks *extremely* badly. Have you looked at SqlObject? (and its associated modules sqlobject.sqlbuilder in particular) http://www.sqlobject.org/module-sqlobject.sqlbuilder.html -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] _bsddb.c ownership
On 3/30/06, Gregory P. Smith [EMAIL PROTECTED] wrote: The pybsddb project does not have its own copy of the code, it justpulls Modules/_bsddb.c and the Lib/bsddb/ directly from the pythonrepository using a script.Ah, excellent, that makes it a lot easier for the rest of python-dev. Its appreciated if people keep Modules/_bsddb.c and Lib/bsddb/backwards compatible with the few revs of python.Otherwise I end up finding out and fixing it myself with ifdefs on the rare occasionswhen I attempt to make another pybsddb module release and find itdoesn't work with an old version. ;)I'll see about making all the recent changes backwardly-compatible. -- 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] building sql queries in python
On 3/30/06, Gregory P. Smith [EMAIL PROTECTED] wrote: Getting off on a tangent here, but I would actually like some decent way of writing SQL queries in Python -- not for importing, but for database access. Constructing bits of SQL out of character strings sucks *extremely* badly.Have you looked at SqlObject?(and its associated modulessqlobject.sqlbuilder in particular)SQLAlchemy (www.sqlalchemy.org ) is also nice, in particular for more complex setups. I found it scales much better to the insanely complex SQL queries that our home-grown PostgreSQL/Perl setup needs, and it handles transactions the same way as our home-grown ORM too. There's plenty of ways to reliably and sanely avoid typing actual SQL in Python. -- 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] Win64 AMD64 (aka x64) binaries available64
Martin v. Löwis wrote: I have now produces a snapshot of a Win64 build for AMD64 processors (also known as EM64T or x64); this is different from IA-64 (which is also known as Itanium)... Anyway, the binaries are http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13199.amd64.msi This is from today's trunk. If you have general remarks/discussion, please post to python-dev. If you have specific bug reports, file them on SF. Bug fixes are particularly welcome. Is this no longer available? BTW: When I build Python for ReleaseAMD64 myself, the exe crashes at the first Py_BuildValue call. Thomas ___ 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
Hello, On 3/29/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 3/29/06, Wolfgang Langner [EMAIL PROTECTED] 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. ... 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? I have no problem with Java, neither with other languages. Most time I have to program in C++ and sometimes in Java. I only suggest to give python solutions a try even if they are not yet equal in quality. But they should be better than SF. 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. I think there are good python solutions and please don't underrate the marketing effect. My opinion is only subjective and to choose one system we must define some criteria's to decide the best one. But something other :-) Even Ruby on Rails uses Trac: http://dev.rubyonrails.org/wiki -- bye by Wolfgang ___ 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: Are you actually *using* this IOClass thing, or is this just a hypothetical proposal? I'm using it. It's not hypothetical. Putting all the info I want in the decorator itself wouldn't be very nice in my case, or at least that's my opinion. One issue is that I'm also abusing a class statement to create a namespace for my extra info. Inserting that as a decorator argument obviously wouldn't be possible... -- 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
[Jack Diederich] Classes have a unique property in that they are the easiest way to make little namespaces in python. [Greg Ewing] For a while now, I've been wondering whether it would be worth having a construct purely for creating little namespaces, instead of abusing a class for this. FWIW, I do not consider it an abuse to use a class to create a small namespace. Essentially that is what it is for -- it matters not whether the class has no methods. What I've been wanting is the ability to easily define functions directly into an existing namespace: class A: pass def A.mymethod(x): return x+1 The latter definition is equivalent to: A.mymethod = lambda(x): x+1 This ability to inject function definitions into an existing namespace is the one missing piece to enable clean use of Protocol OO techniques: a = Object.copy() b = a.copy() def b.f(x): return x+1 c = b.copy() def c.f(x): return x+2 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] building sql queries in python
Thomas Wouters wrote: Have you looked at SqlObject? (and its associated modules sqlobject.sqlbuilder in particular) SQLAlchemy (www.sqlalchemy.org http://www.sqlalchemy.org) is also nice, in particular for more complex setups. There's plenty of ways to reliably and sanely avoid typing actual SQL in Python. Well, yes, but they all seem to be a bit hackish in one way or another -- e.g. SQLAlchemy's requirement to use , |, ~ instead of and, or, not. (That's one of the main motivations behind my Overloadable Boolean Operators PEP, by the way.) I'd like to see some way of attacking this problem head-on, rather than endlessly looking for convoluted ways around it. -- 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
[EMAIL PROTECTED] wrote on 30/03/2006 11:38:30: Jack Diederich wrote: Classes have a unique property in that they are the easiest way to make little namespaces in python. For a while now, I've been wondering whether it would be worth having a construct purely for creating little namespaces, instead of abusing a class for this. I've been thinking about an 'instance' statement that creates an instance of a class: instance my_thing(MyClass): # attribute assignments go here Maybe this would be a use for the proposal a while back where: 'statement' name(args): ... implied name = 'statement'(name, args, namespace) then we could have: namespace foo: ... and interface IFoo(IBar): ... and your instance my_thing(MyClass): ... ? Cheers, Ben -- 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/python%40theyoungfamily.co.uk ___ 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
Raymond Hettinger wrote: FWIW, I do not consider it an abuse to use a class to create a small namespace. Essentially that is what it is for -- it matters not whether the class has no methods. Two problems with that: * The word class in front of it is a misnomer if you've no intention of using it as a class. * It's not a completely blank slate -- it comes with various baggage in the form of __xxx__ attributes (my registration function has to filter those out). Plus some unwanted behaviour such as being callable, and doing magic things with attribute access when the attribute is a descriptor. -- 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?
Fredrik Lundh wrote: Greg Ewing wrote: Firebird could be a solution to this. so a library that doesn't support multiple independent readers/writers on a single file at all is much better than one that does, Where do you get that from? Firebird supports multiple readers/writers perfectly well. 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?
Greg Ewing wrote: Firebird could be a solution to this. so a library that doesn't support multiple independent readers/writers on a single file at all is much better than one that does, Where do you get that from? Firebird supports multiple readers/writers perfectly well. not according to the documentation (which says that the embedded library locks the database file, to prevent other independent processes from accessing the data). but that might of course be misleading or outdated information. do you have a URL that explains how the embedded Firebird component handles concurrency ? (something comparable to http://www.sqlite.org/lockingv3.html, that is.) /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?
On Wed, Mar 29, 2006 at 05:24:32PM +0200, Wolfgang Langner wrote: -1 on db.sql.sqlite. Keep structure flat. Or we are eventually in a Java world with org.something.this.andthat xml.dom.minidom? -- http://www.lexical.org.uk/ | http://covertmusic.com/ | work: [EMAIL PROTECTED] interrupting my train of thought ___ 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
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote on 30/03/2006 11:38:30: Jack Diederich wrote: Classes have a unique property in that they are the easiest way to make little namespaces in python. For a while now, I've been wondering whether it would be worth having a construct purely for creating little namespaces, instead of abusing a class for this. I've been thinking about an 'instance' statement that creates an instance of a class: instance my_thing(MyClass): # attribute assignments go here Maybe this would be a use for the proposal a while back where: 'statement' name(args): ... implied name = 'statement'(name, args, namespace) [...] I like that generalization (since a class definition statement currently does about the same anyway). However, please post that to the python-3000 list as this would be a change for Python 3. Cheers, 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 Thursday 30 March 2006 22:31, M.-A. Lemburg wrote: I don't really care about the name, but please be aware that you are talking about adding a *very* popular module name to the top-level Python namespace if you go for db or database. Why can't we just have the pysqlite package as top-level package, with a slight change in name to prevent clashes with the external distribution, e.g. sqlite ?! Such a module name is less likely to cause problems. Excellent point. Hm. Maybe we should just go with 'sqlite', instead. Anyway, at the moment, there's 'db.sqlite' all checked in and working on a branch, at svn+ssh://[EMAIL PROTECTED]/python/branches/sqlite-integration or, if you use a readonly version http://svn.python.org/python/branches/sqlite-integration (you can use 'svn switch URL' to change a current trunk checkout to the branch without having to checkout a whole new version). It is from sqlite 2.1.3. Gerhard is cutting a 2.2.0 which reduces the requirement for the version of sqlite3 that is required. Currently, it needs 3.2.2 or later. There's tests (which pass), setup.py magic to find a correct sqlite3 version, and the like. Still to do: Windows buildproj Documentation Upgrade to the updated pysqlite once it's out maybe switch from db.sqlite to just sqlite (trivial enough change). 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 Thursday 30 March 2006 22:25, Andrew Walkingshaw wrote: On Wed, Mar 29, 2006 at 05:24:32PM +0200, Wolfgang Langner wrote: -1 on db.sql.sqlite. Keep structure flat. Or we are eventually in a Java world with org.something.this.andthat xml.dom.minidom? given the horror of _xmlplus/xmlcore and whatnot, I'd be hesitant to use the xml package as an example of _anything_ wink ___ 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: xml.dom.minidom? given the horror of _xmlplus/xmlcore and whatnot, I'd be hesitant to use the xml package as an example of _anything_ wink which reminds me -- is that issue still open ? martin? fred? /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] _xmlplus fixup for 2.5
On Thursday 30 March 2006 23:07, Fredrik Lundh wrote: Anthony Baxter wrote: xml.dom.minidom? given the horror of _xmlplus/xmlcore and whatnot, I'd be hesitant to use the xml package as an example of _anything_ wink which reminds me -- is that issue still open ? martin? fred? It looks to me like it's fixed in SVN. http://mail.python.org/pipermail/python-dev/2005-December/058710.html Interestingly, 15 minutes ago I was helping the Ubuntu python packager diagnose exactly the test failure mentioned in this email... 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] _xmlplus fixup for 2.5
Anthony Baxter wrote: It looks to me like it's fixed in SVN. http://mail.python.org/pipermail/python-dev/2005-December/058710.html the issue isn't the one in that message though; it's the one in this message: http://mail.python.org/pipermail/python-dev/2005-December/058752.html I don't agree with the change. You just broke source compatibility between the core package and PyXML. which, I fear, is still unresolved. or ? /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] (finally) getting around to killing __private names from stdlib
I originally raised this a metric age or four ago, and promptly forgot about it - http://mail.python.org/pipermail/python-dev/2004-August/048444.html The concensus seemed to be ok, remove them, but carefully! I've started doing this, and will post a patch on SF when it's done. Before I do this, does anyone want to scream? (see also http://mail.python.org/pipermail/python-dev/2005-December/058555.html ) -- 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] I'm not getting email from SF when assignedabug/patch
On Wed, 2006-03-29 at 23:33 -0800, Neal Norwitz wrote: I'm in favor of having Atlassian setup a system to be used for 3k. It would be completely experimental and could be completely thrown away which should be made clear to Atlassian if we were to do this. I would use the system for evaluation. If we did this, we should also try to ensure we can get all the data out, just in case we want to preserve any of it. I'm sure we can get the data out (unlike SF :), and my guess would be that they'd be fine with such an experimental relationship. They're very cool folks. I'll leave it up to Brett to decide though, since he's chair of the infrastructure committee. I'm happy to ask them 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] I'm not getting email from SF whenassignedabug/patch
On Thu, 2006-03-30 at 09:55 +0200, Fredrik Lundh wrote: so what's the advantage of a freely hosted Atlassian setup compared to a freely hosted Trac setup ? Dunno. I'm sure both will accomplish the job and both will be better than the current situation. I've used Jira and Confluence for almost two years now on a daily basis, and I can personally say that they are among the most intuitive and pleasant to use systems of their kind that I've used. from what I can tell, no big contemporary Python project use Atlassian. they all use Trac. there are thousands of Python developers out there that are used to working with Trac. FWIW, Atlassian has made the same generous offer for Mailman, and I am going to accept it (assuming we can ever get the freakin' data out of SF). -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 whenassignedabug/patch
On Thu, 2006-03-30 at 10:39 +0200, Georg Brandl wrote: Perhaps that Jira is commercial, so it is out of the question for most open-source Python applications. Sorry, I don't follow. Why is a commercial product out of the question for Python? -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 whenassignedabug/patch
Barry Warsaw wrote: On Thu, 2006-03-30 at 10:39 +0200, Georg Brandl wrote: Perhaps that Jira is commercial, so it is out of the question for most open-source Python applications. Sorry, I don't follow. Why is a commercial product out of the question for Python? What I answered to was: from what I can tell, no big contemporary Python project use Atlassian. they all use Trac. there are thousands of Python developers out there that are used to working with Trac. I'm obviously missing something here. I'm not saying it's out of the question for Python, I'm saying that it's out of the question for most open-source projects, which don't have the money or don't want to spend the money on a mere bug tracker, and that this may be the reason that Jira isn't used widely by Python programmers. 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: On Thursday 30 March 2006 22:31, M.-A. Lemburg wrote: I don't really care about the name, but please be aware that you are talking about adding a *very* popular module name to the top-level Python namespace if you go for db or database. Why can't we just have the pysqlite package as top-level package, with a slight change in name to prevent clashes with the external distribution, e.g. sqlite ?! Such a module name is less likely to cause problems. Excellent point. Hm. Maybe we should just go with 'sqlite', instead. Anything, but please no db or database top-level module or package :-) Anyway, at the moment, there's 'db.sqlite' all checked in and working on a branch, at svn+ssh://[EMAIL PROTECTED]/python/branches/sqlite-integration or, if you use a readonly version http://svn.python.org/python/branches/sqlite-integration (you can use 'svn switch URL' to change a current trunk checkout to the branch without having to checkout a whole new version). It is from sqlite 2.1.3. Gerhard is cutting a 2.2.0 which reduces the requirement for the version of sqlite3 that is required. Currently, it needs 3.2.2 or later. There's tests (which pass), setup.py magic to find a correct sqlite3 version, and the like. Still to do: Windows buildproj Documentation Upgrade to the updated pysqlite once it's out maybe switch from db.sqlite to just sqlite (trivial enough change). I take it that this is not going to go into 2.5a1 ?! Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ? Isn't the main argument for having pysqlite included in the core to be able to play around with SQL without relying on external libraries ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 30 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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?
M.-A. Lemburg wrote: [...] Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ? - SQLite sources are 1.57 MiB uncompressed, we wouldn't want to add that to the Python sources download size, would we? - I personally would not want to have the job to bless a certain version of SQLite for being bugfree enough to be used until the next Python minor release. And we wouldn't want to push a Python minor release just somebody found an obscure data corroption bug in a SQLite release - SQLite might not compile on some less common platforms (AIX, HP/UX, Win64, whatever) that Python compiles fine on. - I believe Python is written in more portable C than SQLite. So it might be certain compilers that fail for compiling SQLite. - At some point you might also want a sqlite commandline shell instead of just the shared library, too. All of these are non-issues if we just compile against an installed SQLite on Unix-like system if it can be found. On Windows, I also prefer to have a dynamically linked SQLite Python module. We can distribute the SQLITE3.DLL with Python, and then people could just download an updated SQLITE.DLL from http://sqlite.org/ and overwrite the existing one of the Python installation, *if* an important bug is fixed in SQLite. Isn't the main argument for having pysqlite included in the core to be able to play around with SQL without relying on external libraries ? This, and that you can prototype without having to install and configure a database server. For many applications, the prototype can be the final version. -- 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] I'm not getting email from SFwhenassignedabug/patch
Georg Brandl wrote: What I answered to was: from what I can tell, no big contemporary Python project use Atlassian. they all use Trac. there are thousands of Python developers out there that are used to working with Trac. I'm obviously missing something here. I'm not saying it's out of the question for Python, I'm saying that it's out of the question for most open-source projects, which don't have the money or don't want to spend the money on a mere bug tracker, and that this may be the reason that Jira isn't used widely by Python programmers. Like most commercial tool providers that complete on a market full of open source tools of various quality, Atlassian offers free licenses to non-profits and established open source projects: http://www.atlassian.com/software/jira/pricing.jsp#nonprofit Perforce (who makes an excellent version management system) is another example. We went through very similar discussions back when we moved python from cvs to svn, and ended up picking an open source system that was good enough over a better commercial product, despite the fact that several key developers had extensive experiences of using perforce for large-scale projects. And that's the whole point, of course: if something is widely used by others and is good enough, a project needs very good reasons to pick another tool. /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 whenassignedabug/patch
On Thu, 2006-03-30 at 16:20 +0200, Georg Brandl wrote: I'm not saying it's out of the question for Python, I'm saying that it's out of the question for most open-source projects, which don't have the money or don't want to spend the money on a mere bug tracker, and that this may be the reason that Jira isn't used widely by Python programmers. Gotcha, sorry I misunderstood. BTW, Atlassian does have a program to provide free licenses to open source projects. Here's their FAQ item on it: http://www.atlassian.com/about/licensing/faq.jsp#open_source -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 Friday 31 March 2006 02:04, M.-A. Lemburg wrote: Excellent point. Hm. Maybe we should just go with 'sqlite', instead. Anything, but please no db or database top-level module or package :-) How about sql? wink I can't think of a better name right now - can anyone else, or should it just go in the top level as 'sqlite'? I take it that this is not going to go into 2.5a1 ?! Well, right now the major missing bits for landing it right now are the windows build project and the documentation. I'm pretty comfortable with landing it for a1. It has tests, I've knitted these into the Python regression testing suite and they're all passing fine. I've tested building on systems with a version of sqlite that is acceptable, with no sqlite, and with an old version of sqlite, and the build process handles it all correctly. Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ? For the same reasons we don't include the BerkeleyDB library. Many, many modern operating systems now ship with libsqlite3 (just as they ship with bsddb). While sqlite is nowhere near the size of BerkeleyDB, it's still a non-trivial amount of code. 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] PySet API
On Wed, 2006-03-29 at 23:09 -0500, Raymond Hettinger wrote: Yes, _PySet_Next() is a good compromise for you and me -- it saves you from writing a hack and saves my API from including a bug factory. The only issue is that Martin thinks it to be a crummy idea. Personally, I have no problem with putting-in an undocumented hook for daring people who aspire to swim in quicksand ;-) Of course if it was just a bug factory I might agree. But since it's instead a powerful tool that can be misused if misunderstood, I'd tend to want to document it and explain to people where and why it might or might not be the right hammer for the nail you're trying to pound in. But that's just me. :) The idea is not yet ready for prime-time. If I do it for one of the named operations, I will do it for all (to keep the interface uniform). Which named operations are you thinking of? I haven't yet had the time to work-out the math on whether it would be worthwhile and provide some differential advantage over simply repeating the same operation several times over. My research question is whether work can be saved by controlling the order of operations -- the concept is somewhat like optimizing multi-term matrix multiplication where the total work effort can vary dramatically depending on which matrices are multiplied together first, A((BC)D) vs (AB)(CD) vs (A(BC))D etc. Put in business terms, the question is whether I'm able to leverage the associative and commutative properties of some chained set operations. FWIW, the module already has optimizations to take advantage of the commutative property of binary AND, OR, and SYMMETRIC_DIFFERENCE operations. However, the multi-term optimization probably wait until Py2.6 -- it is too experimental for now. Does that mean you want to make sure the function is insanely fast before you'll add it? Shouldn't you instead decide whether there's even a need for vararg update first and then figure out how to optimize it? IOW, if there's a need for vararg update, let's add the API now so that people can start using it, even if it's not as fast as it could be. Then they'll be especially grateful when you figure out how to make it insanely fast in Python 2.6. If vararg update isn't useful, then there's no point in adding the API, even if it can be made insanely fast. You'd just be wasting your time because no one would use it. It seems backwards to design the implementation first and then the API. An API represents how you want people to use your objects, what operations and semantics you want it to have, what contracts you're guaranteeing and so on. Optimization then is a very nice side benefit. Let me ask this: if you can't make vararg PySet_Update() insanely fast, does that mean you won't add a vararg version? Or you won't add the function at all? I'm all for making things fast, but I just don't believe that in general that should be the primary driver for how you want people to /use/ your objects. -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
[Python-Dev] new article - MapPoint and Python
http://www.mp2kmag.com/a131--python.pythonwin.mappoint.html Let me know if anyone would like to publish this short article on their web site. website @ MP2Kmag dot com for permission and instructions. Thanks, Eric ___ 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: Such a module name is less likely to cause problems. Excellent point. Hm. Maybe we should just go with 'sqlite', instead. except that sqlite was the name used by the first pysqlite generation: $ python2.3 import sqlite sqlite.version '1.1.6' I'm not sure how much trouble reusing this name would cause, but I'm quite sure the amount of trouble is larger than none at all. /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?
Anthony Baxter wrote: On Friday 31 March 2006 02:04, M.-A. Lemburg wrote: Excellent point. Hm. Maybe we should just go with 'sqlite', instead. Anything, but please no db or database top-level module or package :-) How about sql? wink I can't think of a better name right now - can anyone else, or should it just go in the top level as 'sqlite'? I think sqlite is just fine. I take it that this is not going to go into 2.5a1 ?! Well, right now the major missing bits for landing it right now are the windows build project and the documentation. I'm pretty comfortable with landing it for a1. It has tests, I've knitted these into the Python regression testing suite and they're all passing fine. I've tested building on systems with a version of sqlite that is acceptable, with no sqlite, and with an old version of sqlite, and the build process handles it all correctly. Will it also work with e.g. sqlite 2.8.15 (ie. sqlite v3) - this is the standard version on SuSE 9.2. Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ? For the same reasons we don't include the BerkeleyDB library. Many, many modern operating systems now ship with libsqlite3 (just as they ship with bsddb). While sqlite is nowhere near the size of BerkeleyDB, it's still a non-trivial amount of code. If it works with sqlite2 then I agree: these versions are usually available on Unixes. sqlite3 is not as wide-spread yet. What about the Windows build ? Will that contain the necessary DLLs ? Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 30 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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 Lundh wrote: Anthony Baxter wrote: Such a module name is less likely to cause problems. Excellent point. Hm. Maybe we should just go with 'sqlite', instead. except that sqlite was the name used by the first pysqlite generation: $ python2.3 import sqlite sqlite.version '1.1.6' I'm not sure how much trouble reusing this name would cause, but I'm quite sure the amount of trouble is larger than none at all. sqlitedb is not taken yet. -- 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?
M.-A. Lemburg wrote: Will it also work with e.g. sqlite 2.8.15 (ie. sqlite v3) - this is the standard version on SuSE 9.2. No, SQLite 3 has a completely different API than SQLite 2.x. If you need a Python module for it, you can use pysqlite 1.0.1. Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ? For the same reasons we don't include the BerkeleyDB library. Many, many modern operating systems now ship with libsqlite3 (just as they ship with bsddb). While sqlite is nowhere near the size of BerkeleyDB, it's still a non-trivial amount of code. If it works with sqlite2 then I agree: these versions are usually available on Unixes. sqlite3 is not as wide-spread yet. What about the Windows build ? Will that contain the necessary DLLs ? I proposed to link dynamically on Windows, and ship the Windows SQLite3.DLL. This has two advantages: - Python users can upgrade the SQLite3.DLL by a simple download from in case of emergency - we could make it so that win32 Python core developers (or the Python win32 build process) don't have to build SQLite when building Python -- 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] Still looking for volunteer to run Windows buildbot
Gregory P. Smith wrote: FWIW, thats an old BerkeleyDB (yes it'll still work). Python 2.5 should ship built with BerkeleyDB 4.4.20 so thats what buildbot should use if it builds the module. The buildbots now fetch bsddb automatically from http://svn.python.org/projects/external/db-4.4.20/ so the buildbot slave admin doesn't need to do anything here. This also has some 4.4.20 patches already applied. 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?
Fredrik Lundh wrote: xml.dom.minidom? given the horror of _xmlplus/xmlcore and whatnot, I'd be hesitant to use the xml package as an example of _anything_ wink which reminds me -- is that issue still open ? martin? fred? It still is. I wonder whether I should just revert the change. 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] _xmlplus fixup for 2.5
Anthony Baxter wrote: It looks to me like it's fixed in SVN. http://mail.python.org/pipermail/python-dev/2005-December/058710.html Interestingly, 15 minutes ago I was helping the Ubuntu python packager diagnose exactly the test failure mentioned in this email... The problem is that now PyXML is no longer maintainable (not that it has been maintained very well, though): The files that used to be identical in PyXML and Python no longer are identical, so keeping them synchronized adds unreasonable maintenance costs (IMO). 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] unicode vs buffer (array) design issue can crash interpreter
Neal Norwitz wrote:
See http://python.org/sf/1454485 for the gory details. Basically if
you create a unicode array (array.array('u')) and try to append an
8-bit string (ie, not unicode), you can crash the interpreter.
The problem is that the string is converted without question to a
unicode buffer. Within unicode, it assumes the data to be valid, but
this isn't necessarily the case. We wind up accessing an array with a
negative index and boom.
There are several problems combined here, which might need discussion:
- why does the 'u#' converter use the buffer interface if available?
it should just support Unicode objects. The buffer object makes
no promise that the buffer actually is meaningful UCS-2/UCS-4, so
u# shouldn't guess that it is.
(FWIW, it currently truncates the buffer size to the next-smaller
multiple of sizeof(Py_UNICODE), and silently so)
I think that part should just go: u# should be restricted to unicode
objects.
- should Python guarantee that all characters in a Unicode object
are between 0 and sys.maxunicode? Currently, it is possible to
create Unicode strings with either negative or very large Py_UNICODE
elements.
- if the answer to the last question is no (i.e. if it is intentional
that a unicode object can contain arbitrary Py_UNICODE values): should
Python then guarantee that Py_UNICODE is an unsigned type?
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 whenassignedabug/patch
Fredrik Lundh wrote: so what's the advantage of a freely hosted Atlassian setup compared to a freely hosted Trac setup ? I'm obviously missing something here. One thing that you are *obviously* missing (there might be more): Nobody has stepped forward and said I make trac happen. Without somebody (specific) saying that, all technical arguments in favour of that software are futile. 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] Class decorators
Fred L. Drake, Jr. wrote: It's too bad this syntax is ambiguous: class Foo: Docstring here, blah blah blah @implements(IFoo) As this achieves a desirable highlighting of the specialness, without forcing the decorator outside the class. Oh well. Agreed, but... guess we can't have everything. On the other hand, something like: class Foo: Documentation is good. @class implements(IFoo) is not ambiguous. Hmm. It even says what it means. :-) This is quite reminiscent of Ruby to me, where: class Foo: implements(IFoo) basically means: class Foo: pass Foo.implements(IFoo) For a variety of reasons that doesn't work for Python, but what you propose accomplishes the same basic thing. I'm coming in a little late on all this, but I find moving the decorator inside the class statement to be a substantial improvement, even if it is also a trivial improvement ;) Anytime I've done thought experiments about using class decorators, the results is very hard to read. That classes are inherently declarative and open, while functions are imperative and closed, makes the constructs very different. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.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] Win64 AMD64 (aka x64) binaries available64
Thomas Heller wrote: Is this no longer available? Sorry, I just deleted that. I now replaced it with python-2.5.13231.amd64.msi BTW: When I build Python for ReleaseAMD64 myself, the exe crashes at the first Py_BuildValue call. That doesn't happen for me... can you find out why it crashes? (and what is the buildvalue call it crashes on)? 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] alpha problems -- need input
Neal Norwitz wrote: These issues are on HEAD. There might be some others I missed. With cc there are at least 2 issues: * test_file causes interpreter exit due to sys.stdin.seek(-1) * test_pty fails apparently due to whitespace differences http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/18/step-test/0 Should we skip the test for an invalid seek on stdin on osf1? I haven't investigated the test_pty failure further. With gcc, there are also several issues: * test_float and test_struct fail due to NaN handling * test_long fails * test_ctypes ... test_ctypes fails because _findLib() doesn't seem to work properly on OSF1. Note: libc.so = /usr/shlib/libc.so ERROR: test_find (ctypes.test.test_loading.LoaderTest) -- Traceback (most recent call last): File /net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/test/test_loading.py, line 40, in test_find cdll.find(name) File /net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/_loader.py, line 205, in find raise OSError(Library %r not found % name) OSError: Library 'c' not found The ctypes findLib stuff for 'os.name == posix' was written by Andreas Degert, he used fancy calls to gcc, /sbin/ldconfig, and objdump to find the shared lib that would be used for the linker's -llibname flag. Apparently this only works on *some* systems. On OSX, Bob Ippolito's macholib is used. If someone could implement this for other systems it would be great, otherwise it would probably be best to enable this test only on linux . Thomas ___ 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] Win64 AMD64 (aka x64) binaries available64
Martin v. Löwis wrote: Thomas Heller wrote: Is this no longer available? Sorry, I just deleted that. I now replaced it with python-2.5.13231.amd64.msi Thanks, I'll try that. BTW: When I build Python for ReleaseAMD64 myself, the exe crashes at the first Py_BuildValue call. That doesn't happen for me... can you find out why it crashes? (and what is the buildvalue call it crashes on)? In sys_getwindowsversion: return Py_BuildValue(s, ver.dwMajorVersion, ver.dwMinorVersion, ver.dwBuildNumber, ver.dwPlatformId, ver.szCSDVersion); The crash disappears if I change the first parameter in the Py_BuildValue call to s. No idea why. With this change, I can start the exe without a crash, but sys.versioninfo starts with (IIRC) (2, 0, 5,...). Thomas ___ 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 assigned a bug/patch
Martin v. Löwis wrote: I'm obviously missing something here. One thing that you are *obviously* missing (there might be more): Nobody has stepped forward and said I make trac happen. Without somebody (specific) saying that, all technical arguments in favour of that software are futile. I'm quite sure I've already pointed to http://www.python-hosting.com/freetrac which could be used by the Python 3000 activity in order to evaluate Trac, and to http://www.python-hosting.com/shared_hosting plus a small fraction of the PSF budget for the Python code, if Trac is found to be good enough, and provided that the PH folks think that it's a good idea to host core development on their platform (I assume we have pretty good stats for how svn.python.org is being used). I can ask them for a test py3k account, if there's any interest. /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 SFwhenassignedabug/patch
Fredrik Lundh wrote: Georg Brandl wrote: What I answered to was: from what I can tell, no big contemporary Python project use Atlassian. they all use Trac. there are thousands of Python developers out there that are used to working with Trac. I'm obviously missing something here. I'm not saying it's out of the question for Python, I'm saying that it's out of the question for most open-source projects, which don't have the money or don't want to spend the money on a mere bug tracker, and that this may be the reason that Jira isn't used widely by Python programmers. Like most commercial tool providers that complete on a market full of open source tools of various quality, Atlassian offers free licenses to non-profits and established open source projects: http://www.atlassian.com/software/jira/pricing.jsp#nonprofit Okay, I wasn't aware of that. 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?
M.-A. Lemburg wrote: Anthony Baxter wrote: On Friday 31 March 2006 02:04, M.-A. Lemburg wrote: Excellent point. Hm. Maybe we should just go with 'sqlite', instead. Anything, but please no db or database top-level module or package :-) How about sql? wink I can't think of a better name right now - can anyone else, or should it just go in the top level as 'sqlite'? I think sqlite is just fine. sqlite is problematic since the old PySQLite 1.0 (2.x wrapper) had this name. But I'm in favour of a flat name too -- let's use sqlite3. 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] Win64 AMD64 (aka x64) binaries available64
Thomas Heller wrote: In sys_getwindowsversion: return Py_BuildValue(s, ver.dwMajorVersion, ver.dwMinorVersion, ver.dwBuildNumber, ver.dwPlatformId, ver.szCSDVersion); The crash disappears if I change the first parameter in the Py_BuildValue call to s. No idea why. With this change, I can start the exe without a crash, but sys.versioninfo starts with (IIRC) (2, 0, 5,...). Very strange. What is your compiler version (first line of cl /?)? 'H' isn't exactly right, since these are DWORDs, so they are unsigned longs, not unsigned ints (so 'k' should be right), however, the actually bug apparently is elsewhere - something like memory corruption. Can you find out what the value of szCSDVersion is (e.g. by putting a printf right before that)? 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 assigned a bug/patch
Fredrik Lundh wrote: I can ask them for a test py3k account, if there's any interest. I'm personally not very much interested in a Py3k tracker; I don't see myself using it. So I'm not interested in a trac-based one, either. As for python-hosting.com: Somebody would *still* have to set this up, manage to import the data, manage accounts, manage to make it known etc. The actual hardware to run it on is the least of my concerns - xs4all provides that very nicely. I don't see anything that could be saved by moving things from xs4all to python-hosting. 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] PySet API
The idea is not yet ready for prime-time. If I do it for one of the named operations, I will do it for all (to keep the interface uniform). Which named operations are you thinking of? s.union(t), s.intersection(t), s.difference(t), s.symmetric_difference(t), s.update(t), s.intersection_update(t), s.difference_update(t), s.symmetric_difference_update(t) if you can't make vararg PySet_Update() insanely fast, does that mean you won't add a vararg version? Right. Please leave this one alone. I still need to work on this part of the API and do not currently have the spare clock cycles to do it right now. You don't HAVE to jam something in right away. Please let it continue to cook and not muck it up through over-enthusiasm. If I had time to explain/debate every darned aspect of what is under consideration, then it would have been done already. The fierce insistence for the patch is pre-mature and is grotesquely out-of-proportion to any potential benefit. Please do not jam this one down my throat -- the function is not necessary to have right away -- you're talking about nanoseconds of efficiency and a microscopically shorter call. Sorry, I need to stop wasting time on this thread. It has consumed far too much development time already. Please write a one-line macro for yourself and leave this alone so I can continue the development efforts at a thoughtful pace. 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] Win64 AMD64 (aka x64) binaries available64
Martin v. Löwis wrote: Thomas Heller wrote: In sys_getwindowsversion: return Py_BuildValue(s, ver.dwMajorVersion, ver.dwMinorVersion, ver.dwBuildNumber, ver.dwPlatformId, ver.szCSDVersion); The crash disappears if I change the first parameter in the Py_BuildValue call to s. No idea why. With this change, I can start the exe without a crash, but sys.versioninfo starts with (IIRC) (2, 0, 5,...). Very strange. What is your compiler version (first line of cl /?)? 'H' isn't exactly right, since these are DWORDs, so they are unsigned longs, not unsigned ints (so 'k' should be right), however, the actually bug apparently is elsewhere - something like memory corruption. Can you find out what the value of szCSDVersion is (e.g. by putting a printf right before that)? I would prefer to examine this further when I'm able to compile Python on the AMD64 machine. Currently I'm not, because the VSExtCompiler Plugin cannot determine the SDK path from the registry. This is vsextcomp 0.6. I have installed the 2003 Server SP1 SDK. I tried installing the Feb 2003 SDK (since that did work on a 32-bit machine), but this won't install on XP-64. Thomas ___ 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: On Friday 31 March 2006 02:04, M.-A. Lemburg wrote: Excellent point. Hm. Maybe we should just go with 'sqlite', instead. Anything, but please no db or database top-level module or package :-) How about sql? wink I can't think of a better name right now - can anyone else, or should it just go in the top level as 'sqlite'? I take it that this is not going to go into 2.5a1 ?! Well, right now the major missing bits for landing it right now are the windows build project and the documentation. I'm pretty comfortable with landing it for a1. It has tests, I've knitted these into the Python regression testing suite and they're all passing fine. I've tested building on systems with a version of sqlite that is acceptable, with no sqlite, and with an old version of sqlite, and the build process handles it all correctly. Apart from the tests issue (see python-checkins), doesn't version 1.0 of PySQLite also use the name _sqlite for its C module? If so, ours should be renamed too (_sqlite3?) to avoid breaking old apps. 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
[Python-Dev] xmlrpclib.binary missing?
The current 2.4 and 2.5 docs mention that the xmlrpclib has a function called binary which converts any python value to a Binary object. However, this function does not exist in either 2.4.3 or 2.5. The Binary constructor accepts a data parameter, so I would say just remove mention of the binary function from the docs and leave the implementation as-is. Cheers, Chris ___ 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 sqlite is just fine. I do, too. 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] xmlrpclib.binary missing?
On Thu, Mar 30, 2006, Chris AtLee wrote: The current 2.4 and 2.5 docs mention that the xmlrpclib has a function called binary which converts any python value to a Binary object. However, this function does not exist in either 2.4.3 or 2.5. The Binary constructor accepts a data parameter, so I would say just remove mention of the binary function from the docs and leave the implementation as-is. Please file a bug on SF and report it back here so that we don't lose track of this. -- 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] xmlrpclib.binary missing?
On 3/30/06, Aahz [EMAIL PROTECTED] wrote: On Thu, Mar 30, 2006, Chris AtLee wrote: The current 2.4 and 2.5 docs mention that the xmlrpclib has a function called binary which converts any python value to a Binary object. However, this function does not exist in either 2.4.3 or 2.5. The Binary constructor accepts a data parameter, so I would say just remove mention of the binary function from the docs and leave the implementation as-is. Please file a bug on SF and report it back here so that we don't lose track of this. Sure, this is filed as bug #1461610. Cheers, Chris ___ 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] Fwd: Python 2.5 update
-- Forwarded message -- From: Martin Blais [EMAIL PROTECTED] Date: Mar 29, 2006 10:32 PM Subject: Python 2.5 update To: [EMAIL PROTECTED] Hi I was thinking of a new action append_const to optparse, so I googled it to check if anybody else had been thinking about the same idea, and *surprise* -- not really -- I discover that it's already been implemented and included in Optik 1.5. Now, I checked in the upcoming Python 2.5 source code -- the Subversion repository -- and it still is at 1.5a2, which does not contain this code. And the stdlib uses an alpha version? Hmmm. What is the process for upgrading the stdlib version of optparse? Are there any plans to upgrade the stdlib's 1.5a2 to the stable 1.5? It seems like it has been released for a while... If there are no plans to do that, what is the process exactly, and can I nudge it with a little bit of armwork somehow? cheers, ___ 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] 2.5 trunk built for Windows available?
Hi, for the Bug Day, someone asked me if there is a prebuilt trunk for Windows available somewhere so that he could participate. Martin: I read you've built for a snapshot AMD64, is there one for x86 too? 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?
So do I. On 3/30/06, Bill Janssen [EMAIL PROTECTED] wrote: I think sqlite is just fine. I do, too. Bill -- --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
[Python-Dev] Nasty trunk test failures
test_tokenize started failing on all the trunk buildbots immediately
after this seemingly unrelated checkin:
Author: armin.rigo
Date: Thu Mar 30 16:04:02 2006
New Revision: 43458
Modified:
python/trunk/Lib/test/test_index.py
python/trunk/Objects/abstract.c
python/trunk/Objects/typeobject.c
Log:
Minor bugs in the __index__ code (PEP 357), with tests.
I haven't gotten anywhere with this. test_tokenize doesn't fail in
isolation on my box, and at one point didn't even fail after using -f
to reproduce all the steps up to and including test_tokenize from a
failing -r run.
I do have a long sequence of tests now ending with test_tokenize that
fails on my box provided I use -uall (and I should note that
test_index is not in this sequence). I'm using a debug build here,
and don't know about a release build. Alas, it takes a long time to
run, so progress this way is slow. Worse, since this is so flaky I
doubt it's going to lead to something interesting anyway.
More eyeballs? I didn't see anything obviously wrong in Armin's
checkin. Maybe someone else would. Or maybe it's just managing to
provoke a pre-existing C problem.
...
Eww! test_tokenize _does_ fail in isolation here, but only if I use -uall(!):
C:\Code\python\PCbuildpython_d ../Lib/test/regrtest.py test_tokenize
test_tokenize
1 test OK.
[25131 refs]
C:\Code\python\PCbuildpython_d ../Lib/test/regrtest.py -uall test_tokenize
test_tokenize
test test_tokenize crashed -- class 'exceptions.AssertionError':
1 test failed:
test_tokenize
[15147 refs]
OK, test_tokenize does a hell of a lot more work when -uall is
specified. After applying this patch, test_tokenize fails very
quickly (although you still need -uall):
Index: test_tokenize.py
===
--- test_tokenize.py(revision 43462)
+++ test_tokenize.py(working copy)
@@ -34,6 +34,7 @@
testdir = os.path.dirname(f) or os.curdir
testfiles = glob.glob(testdir + os.sep + 'test*.py')
+testfiles = [testdir + os.sep + 'test_index.py']
if not is_resource_enabled('compiler'):
testfiles = random.sample(testfiles, 10)
IOW, it's specifically the new test_index.py that test_tokenize fails
on. I'm not sure what test_tokenize is doing, but if someone else is,
that seems like a good hint ;-)
___
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
Martin Nobody has stepped forward and said I make trac happen. Hasn't trac already happened in the sense that it's installed (by Tim Parkin on the Pollenation website) and in use by the website maintainers? Seems the only major hurdle is the extraction of history from SF. 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] Nasty trunk test failures
On 3/30/06, Tim Peters [EMAIL PROTECTED] wrote: test_tokenize started failing on all the trunk buildbots immediately after this seemingly unrelated checkin: tokenize seems to be mishandling this line: assert 6 .__index__() == 6 Note the space between '6' and '.'. I'm guessing that the untokenization of this somehow drops the space; this seems to be a bug in untokenize() which probably should add a safety space after names as well as numbers. Yes, this fixes the problem: Index: tokenize.py === --- tokenize.py (revision 43463) +++ tokenize.py (working copy) @@ -182,7 +182,7 @@ for tok in iterable: toknum, tokval = tok[:2] -if toknum == NAME: +if toknum in (NAME, NUMBER): tokval += ' ' if toknum == INDENT: I'll check this in. Then there's another (shallow) problem that only occurs when I run test_tokenize.py directly -- the doctest for decistmt() has-3.21716034272e-007 but (on my box) this outputs -3.21716034272e-07. That doesn't seem to bother it when run via regrtest.py. I'm not sure what's at fault here. -- --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
[EMAIL PROTECTED] wrote: Hasn't trac already happened in the sense that it's installed (by Tim Parkin on the Pollenation website) and in use by the website maintainers? Seems the only major hurdle is the extraction of history from SF. That isn't actually the case. Test data would be available; somebody would need to import them. 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] Fwd: Python 2.5 update
Martin Blais wrote: What is the process for upgrading the stdlib version of optparse? Very simple: the author of the library would have to contribute it. Actually, if the changes where contributed by Optik contributors, they would have to contribute them to Python. Are there any plans to upgrade the stdlib's 1.5a2 to the stable 1.5? I don't have any such plans: I cannot just incorporate somebody else's library into Python without his permission. If there are no plans to do that, what is the process exactly, and can I nudge it with a little bit of armwork somehow? Ask the authors to act. 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] 2.5 trunk built for Windows available?
Georg Brandl wrote: for the Bug Day, someone asked me if there is a prebuilt trunk for Windows available somewhere so that he could participate. Martin: I read you've built for a snapshot AMD64, is there one for x86 too? Not at the moment, and I might not have time tomorrow to produce one. 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] PySet API
On Thu, 2006-03-30 at 13:09 -0500, Raymond Hettinger wrote: Please leave this one alone. I still need to work on this part of the API and do not currently have the spare clock cycles to do it right now. You don't HAVE to jam something in right away. Please let it continue to cook and not muck it up through over-enthusiasm. If I had time to explain/debate every darned aspect of what is under consideration, then it would have been done already. The fierce insistence for the patch is pre-mature and is grotesquely out-of-proportion to any potential benefit. Please do not jam this one down my throat -- the function is not necessary to have right away -- you're talking about nanoseconds of efficiency and a microscopically shorter call. Sorry, I need to stop wasting time on this thread. It has consumed far too much development time already. Please write a one-line macro for yourself and leave this alone so I can continue the development efforts at a thoughtful pace. As per your comment in patch 1458476, I will add _PySet_Update() and consider this thread closed. -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?
Anthony Baxter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Anything, but please no db or database top-level module or package :-) How about sql? wink Whereas I am quite happy with a 'db' package, and would like to see other db stuff put under it. tjr ___ 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 [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I proposed to link dynamically on Windows, and ship the Windows SQLite3.DLL. This has two advantages: - Python users can upgrade the SQLite3.DLL by a simple download from in case of emergency +1 and thanks from a Windows user tjr ___ 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 Lundh wrote: not according to the documentation (which says that the embedded library locks the database file, to prevent other independent processes from accessing the data). I think that means other *non-Firebird* processes. Firebird itself uses a system of file locks and transactions to manage concurrent access by different Firebird applications. Just to make sure I wasn't imagining things, I ran two instances of a program of mine that uses Firebird, without server, accessing the same database, and both worked fine. They can independently access different parts of the database, and if they try to update the same part at the same time, deadlocks are reported as appropriate. On the whole I'm very impressed with Firebird. I've found it to be nothing less than sleek, efficient, powerful and reliable. I'd encourage anyone looking for a database, embedded or otherwise, to give it a go. -- 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?
M.-A. Lemburg wrote: I don't really care about the name, but please be aware that you are talking about adding a *very* popular module name to the top-level Python namespace if you go for db or database. This would only be an issue for an application that had a private module calle db, since nobody will be trying to publish a top-level module for general use with such a generic name. In that case the application's module would just shadow the db package and the app would continue to work. If the app's author at some point wanted to start using stuff from the new db package, he would just have to rename his module. -- 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] I'm not getting email from SF when assigned a bug/patch
On 3/30/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 3/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Fredrik Lundh wrote: I can ask them for a test py3k account, if there's any interest. I'm personally not very much interested in a Py3k tracker; I don't see myself using it. So I'm not interested in a trac-based one, either. Me neither. It's too early. Same here. Please move any more comments about infrastructure to the infrastructure list (http://mail.python.org/mailman/listinfo/infrastructure/). But do realize the committee is not discussing trackers yet. We are still trying to get our SF data out so that can be imported into a tracker to test its use (we need large scale bugs in it to stress it and get a feel for its search abilities, etc.). I am going to be picky about keeping the intfrastructure email traffic focued on the task at hand. Tracker discussions will be mostly ignored by me until I send out the official call for tracker suggestions with volunteer maintainers. At that point we can figure out what trackers to consider and who will be in charge of getting the test setup going. -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
[Python-Dev] reference leaks, __del__, and annotations
The checkins list has been struggling with generator reference leaks; the latest conclusion was that some are unavoidable because of __del__ cycles. That sort of defeats the purpose of resource managers. (Yes, it can be worked around on a case-by-case basis.) As I see it, part of the problem is that (1) When there is a cycle, python refuses to guess. (2) There is no way for a __del__ method to hint at ordering constraints. (3) There is no lightweight version of __del__ to say I don't care about ordering constraints. How about using an (optional) annotation on __del__ methods, to indicate how cycles should be broken? As a strawman proposal: deletes = [obj for obj in cycle if hasattr(obj, cycle)] deletes.sort() for obj in deletes: obj.__del__() Lightweight __del__ methods (such as most resource managers) could set the cycle attribute to True, and thereby ensure that they don't cause unbreakable cycles. Fancier object frameworks could use different values for the cycle attribute. Any object whose __del__ is not annotated will still be at least as likely to get finalized as it is today. -jJ ___ 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] reference leaks, __del__, and annotations
(Apologies for the thinko -- corrected because it was in the example code.) The checkins list has been struggling with generator reference leaks; the latest conclusion was that some are unavoidable because of __del__ cycles. That sort of defeats the purpose of resource managers. (Yes, it can be worked around on a case-by-case basis.) As I see it, part of the problem is that (1) When there is a cycle, python refuses to guess. (2) There is no way for a __del__ method to hint at ordering constraints. (3) There is no lightweight version of __del__ to say I don't care about ordering constraints. How about using an (optional) annotation on __del__ methods, to indicate how cycles should be broken? As a strawman proposal: deletes = [(obj.__del__.cycle, obj) for obj in cycle if hasattr(obj, __del__) and hasattr(obj.__del__, cycle)] deletes.sort() for (cycle, obj) in deletes: obj.__del__() Lightweight __del__ methods (such as most resource managers) could set the cycle attribute to True, and thereby ensure that they won't cause unbreakable cycles. Fancier object frameworks could use different values for the cycle attribute. Any object whose __del__ is not annotated will still be at least as likely to get finalized as it is today. -jJ ___ 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] Class decorators
Phillip J. Eby wrote: I don't even recall seeing any examples of class decorators being used without arguments! I have often started with a function, and ended up replacing it with a callable object so that I could save state without resorting to defalt args or worse. I would prefer to decorate these exactly like the functions they replace. -jJ ___ 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] reference leaks, __del__, and annotations
Jim Jewett wrote: The checkins list has been struggling with generator reference leaks; the latest conclusion was that some are unavoidable because of __del__ cycles. That sort of defeats the purpose of resource managers. Seems to me we need a whole new approach to finalization that's friendly to cyclic gc, such as a way of registering a finalizer that doesn't depend on the original object. If such a mechanism were available, could it be used instead of a __del__ method to clean up after a generator? (I'm asking because I'm not sure exactly what a generator __del__ needs to do.) As a strawman proposal: deletes = [(obj.__del__.cycle, obj) for obj in cycle if hasattr(obj, __del__) and hasattr(obj.__del__, cycle)] deletes.sort() for (cycle, obj) in deletes: obj.__del__() I think we need to be very careful about doing anything like this. From what Tim said recently, the consequences of an object getting its __del__ annotation wrong could be as bad as crashing the interpreter. -- 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] Nasty trunk test failures
[Guido] tokenize seems to be mishandling this line: assert 6 .__index__() == 6 Note the space between '6' and '.'. I'm guessing that the untokenization of this somehow drops the space; this seems to be a bug in untokenize() which probably should add a safety space after names as well as numbers. Yes, this fixes the problem: Thanks! It's nice to get a break from the you found it, you fix it rule ;-) Then there's another (shallow) problem that only occurs when I run test_tokenize.py directly -- the doctest for decistmt() has-3.21716034272e-007 but (on my box) this outputs -3.21716034272e-07. That doesn't seem to bother it when run via regrtest.py. I'm not sure what's at fault here. I'll return the favor, then: decistmt's doctests don't run at all when test_tokenize is run indirectly via regrtest.py. I'll fix that (and worm around the Windows-specific expected output). ___ 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] 2.5 trunk built for Windows available?
[Georg Brandl] for the Bug Day, someone asked me if there is a prebuilt trunk for Windows available somewhere so that he could participate. Martin: I read you've built for a snapshot AMD64, is there one for x86 too? If someone can explain what prebuilt trunk means, exactly, maybe I can do it. ___ 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] alpha problems -- need input
Disabling a test on a platform is usually a bad thing, overall. The purpose of the test suite isn't to get a lot of green buildbot boxes 0.5 wink, it's to determine whether Python works as expected. If a platform bug causes some test to fail, then that test _should_ fail on that platform -- it's not a Python bug, after all, and users on that platform aren't served by hiding that platform bugs cause Python tests to fail. If they try the same things in their programs they'll fail there too, and the test suite is supposed to warn them about that. If the primary goal here is really to make the alpha Tru64 5.1 buildbot columns green, then maybe the Alpha needs a different test runner, to exclude the tests that are doomed to fail due to Alpha bugs. ... With gcc, there are also several issues: * test_float and test_struct fail due to NaN handling * test_long fails Which version of gcc is in use? Alpha hardware has incomplete support for IEEE endcase semantics, and it usually requires a special compiler option to generate code that hides the HW limitations. That you didn't list the above as failures using the native cc strongly suggests that we're missing a necessary gcc Alpha trick. You can go to: http://gcc.gnu.org/onlinedocs/ pick the version of gcc, and drill down to the DEC Alpha Options chapter for that version to see the Alpha tricks available. Looks like compiling with -mieee would be an excellent idea for Python, and looks like we're not using that now. I've never used an Alpha, but I recall that this suggestion fixed other peoples' problems :-) ___ 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?
Terry Reedy wrote: Gerhard Häring [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I proposed to link dynamically on Windows, and ship the Windows SQLite3.DLL. This has two advantages: - Python users can upgrade the SQLite3.DLL by a simple download from in case of emergency +1 and thanks from a Windows user This binary depends on msvcrt.dll. Does anybody know whether this could cause a problem? IOW, is any of the forbidden API used across the DLL boundary (in particular: memory management, stdio, locales)? 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] _xmlplus fixup for 2.5
On 3/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote: The problem is that now PyXML is no longer maintainable (not that it has been maintained very well, though): The files that used to be identical in PyXML and Python no longer are identical, so keeping them synchronized adds unreasonable maintenance costs (IMO). I don't know what the differences are. Are they large? Can we copy the changes from Python back into PyXML? Or modify both PyXML and Python so they are the same? Could we create a patch that would be applied on importing PyXML to make things easier? 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] I'm not getting email from SF when assigned abug/patch
Brett Cannon wrote: Same here. Please move any more comments about infrastructure to the infrastructure list (http://mail.python.org/mailman/listinfo/infrastructure/). But do realize the committee is not discussing trackers yet. We are still trying to get our SF data out so that can be imported into a tracker to test its use oh, I forgot that the Procrastination Stop energy Foundation was involved in this. see you all in 2015. /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] 2.5 trunk built for Windows available?
Tim Peters wrote: for the Bug Day, someone asked me if there is a prebuilt trunk for Windows available somewhere so that he could participate. Martin: I read you've built for a snapshot AMD64, is there one for x86 too? If someone can explain what prebuilt trunk means, exactly, maybe I can do it. If you have a release build of a Python trunk working copy, cd Tools\msi, run msi.py (with a Python version that has win32com), and make the resulting msi file available somewhere. 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] _xmlplus fixup for 2.5
Neal Norwitz wrote: I don't know what the differences are. Are they large? Can we copy the changes from Python back into PyXML? Or modify both PyXML and Python so they are the same? Could we create a patch that would be applied on importing PyXML to make things easier? Primarily, things got renamed from xml to xmlcore in different places. Porting them to PyXML is besides the point of the renaming, because PyXML then would have to provide an xmlcore package, too. As for actual solution strategies: I haven't yet researched any. Fred indicated he has something in mind, but hasn't been forthcoming over the past few months. 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] alpha problems -- need input
On 3/30/06, Tim Peters [EMAIL PROTECTED] wrote:
Disabling a test on a platform is usually a bad thing, overall. The
Agreed.
purpose of the test suite isn't to get a lot of green buildbot boxes
0.5 wink, it's to determine whether Python works as expected. If a
platform bug causes some test to fail, then that test _should_ fail on
that platform -- it's not a Python bug, after all, and users on that
platform aren't served by hiding that platform bugs cause Python tests
to fail. If they try the same things in their programs they'll fail
there too, and the test suite is supposed to warn them about that.
Fair enough. However, it's not just that the test fails. It's that
Python exits. Hell, if I'm in bash, bash dies too! If I'm running
python in gdb, gdb dies. I tried building a trace (supposedly like
truss), but that crashes while python is starting up. So we can never
get results on which tests failed, since we can never finish
reasonably.
When I single stepped in gdb, the code died when executing the
equivalent of fseek(stdin, -1, 0);
I tried to seek(-1) on a different file and that was ok. The test is
meant to stress a failure condition, but fseek is expected to return.
Upgrading the machine isn't an option (it's not mine), and I don't
know that upgrading would fix the problem.
If the primary goal here is really to make the alpha Tru64 5.1
buildbot columns green, then maybe the Alpha needs a different test
runner, to exclude the tests that are doomed to fail due to Alpha
bugs.
That's not my goal. I just want to get as much information as
possible. I also don't want to skip all of test_file, only one test
case.
...
With gcc, there are also several issues:
* test_float and test_struct fail due to NaN handling
* test_long fails
Which version of gcc is in use? Alpha hardware has incomplete support
4.0.1.
Looks like compiling with
-mieee
would be an excellent idea for Python, and looks like we're not using
that now. I've never used an Alpha, but I recall that this suggestion
fixed other peoples' problems :-)
Since we are already using -ieee for the platform cc, I thought this
was an excellent idea as well. I almost put in my message that I
tried it along with a couple other options. But I guess I was on
crack or something, cause I tried it again, being very careful (ie,
not trying to do 4 things at once) and voila! it worked. Thanks Tim!
It fixed the problem with test_float, test_long, and test_struct. The
thing that seems really odd is that I was sure test_pty passed before
with gcc, now it's failing. Given the problem with -mieee, I was
probably just very confused when I did everything the first time.
So now the failures with gcc are: test_file, test_pty, test_ctypes.
I believe this is the same as with the platform cc.
Additional ctypes failure info for Thomas:
AssertionError: ('dlopen: Cannot map library libc.so.6', 'libc.so.6',
('posix', 'osf1V5'))
Note: there is no version info on osf1, ie no 6. ldd python shows:
libc.so = /usr/shlib/libc.so
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] 2.5 trunk built for Windows available?
Tim Peters wrote: [Georg Brandl] for the Bug Day, someone asked me if there is a prebuilt trunk for Windows available somewhere so that he could participate. Martin: I read you've built for a snapshot AMD64, is there one for x86 too? If someone can explain what prebuilt trunk means, exactly, maybe I can do it. a compiled version of the current development trunk ? I guess an installer would be nice, but a ZIP archive is probably good enough. /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 assigned abug/patch
Brett Cannon wrote: On 3/28/06, Martin v. Löwis [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Roundup is there now, right (sans SF export)? Richard Jones has an SF importer for one of the two XML-like formats, the one that is correct XML but with incomplete data. The other format, which has complete data but is ill-formed XML, has no importer into roundup at the moment. Trac is being used by the folks doing the new website. What other candidates are being considered? My view is that nothing should be considered unless there is a) a volunteer to operate the tracker (or, failing that, somebody who does it for money), and b) an importer of whatever data SF can provide. And as the chair of the infrastructure committee, those are the base requirements for a tracker to be considered. Once we have the complete SF data I will put out a call for proposals for trackers along with who has volunteered to manage them so that people can band together to help push their favorite tracker. But as of right now the committe just wants to get a clean dump of our SF data to work off of (yes, we could start a tracker from scratch but we want the SF data anyway and so we are going through the hassle of getting it off now and as a test data set for the various trackers). -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/python-python-dev%40m.gmane.org -- Robert Kern [EMAIL PROTECTED] I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ 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 assigned abug/patch
Guido van Rossum wrote: I can ask them for a test py3k account, if there's any interest. I'm personally not very much interested in a Py3k tracker; I don't see myself using it. So I'm not interested in a trac-based one, either. Me neither. It's too early. I wasn't really expecting you to start collecting *bug reports* for Py3k at this time; you can use Trac for a lot more than that, if you want (including todo/totry/tothinkabout lists, milestones, pep editing sandboxes, etc). /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 assigned abug/patch
Brett Cannon wrote: On 3/28/06, Martin v. Löwis [EMAIL PROTECTED] wrote: My view is that nothing should be considered unless there is a) a volunteer to operate the tracker (or, failing that, somebody who does it for money), and b) an importer of whatever data SF can provide. And as the chair of the infrastructure committee, those are the base requirements for a tracker to be considered. Once we have the complete SF data I will put out a call for proposals for trackers along with who has volunteered to manage them so that people can band together to help push their favorite tracker. FWIW: Trac has a Sourceforge bug tracker import script: http://projects.edgewall.com/trac/browser/trunk/contrib/sourceforge2trac.py Apologies: for the other blank reply. -- Robert Kern [EMAIL PROTECTED] I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ 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 ncoghlan at gmail.com writes: 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. delurk Is there any reason why they can't be view objects - a dictionary has keys, has values, has items - rather than methods returning view objects: for k in mydict.keys: ... for v in mydict.values: ... for k, v in mydict.items: ... For backward compatibility with Py2.x, calling them would raise a DeprecationWarning and return a list. This could even be introduced in 2.x (with a PendingDeprecationWarning instead?). Cheers, -T. ___ 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
Robert Kern wrote: Apologies: for the other blank reply. oh, I don't know about that -- the eco quote made perfect sense ;-) /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
