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
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
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
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
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
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
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
[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.
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
[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
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
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
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
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]
[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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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?
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
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
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.
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.
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
Thomas Heller wrote:
In sys_getwindowsversion:
return Py_BuildValue(s,
ver.dwMajorVersion,
ver.dwMinorVersion,
ver.dwBuildNumber,
ver.dwPlatformId,
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,
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),
Martin v. Löwis wrote:
Thomas Heller wrote:
In sys_getwindowsversion:
return Py_BuildValue(s,
ver.dwMajorVersion,
ver.dwMinorVersion,
ver.dwBuildNumber,
ver.dwPlatformId,
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
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
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
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,
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.
-- 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,
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
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
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
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
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
[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
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
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.
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
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
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
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
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
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
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
(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
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
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
[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
[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.
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 --
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
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
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
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
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
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
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,
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
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
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
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.
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:
91 matches
Mail list logo
