Re: [Python-Dev] I'm not getting email from SF when assignedabug/patch

[Fredrik Lundh]

Robert Kern wrote:

> Apologies: for the other blank reply.

oh, I don't know about that -- the eco quote made perfect sense ;-)





___
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 :)

[Taro Ogawa]

Nick Coghlan  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.

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 assigned abug/patch

[Robert Kern]

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] I'm not getting email from SF when assigned abug/patch

[Fredrik Lundh]

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).





___
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

[Robert Kern]

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] 2.5 trunk built for Windows available?

[Fredrik Lundh]

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.





___
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]

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] _xmlplus fixup for 2.5

[Martin v. Löwis]

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] 2.5 trunk built for Windows available?

[Martin v. Löwis]

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] I'm not getting email from SF when assigned abug/patch

[Fredrik Lundh]

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.





___
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]

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] pysqlite for 2.5?

[Martin v. Löwis]

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] alpha problems -- need input

[Tim Peters]

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] 2.5 trunk built for Windows available?

[Tim Peters]

[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] Nasty trunk test failures

[Tim Peters]

[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] reference leaks, __del__, and annotations

[Greg Ewing]

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

[Python-Dev] Class decorators

[Jim Jewett]

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]

(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] reference leaks, __del__, and annotations

[Jim Jewett]

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] I'm not getting email from SF when assigned a bug/patch

[Brett Cannon]

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

Re: [Python-Dev] pysqlite for 2.5?

[Greg Ewing]

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] pysqlite for 2.5?

[Greg Ewing]

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?

[Terry Reedy]

"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?

[Terry Reedy]

"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"? 

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] PySet API

[Barry Warsaw]

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] 2.5 trunk built for Windows available?

[Martin v. Löwis]

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] Fwd: Python 2.5 update

[Martin v. Löwis]

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] I'm not getting email from SF whenassignedabug/patch

[Martin v. Löwis]

[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] Nasty trunk test failures

[Guido van Rossum]

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

[skip]

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

[Python-Dev] Nasty trunk test failures

[Tim Peters]

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\PCbuild>python_d ../Lib/test/regrtest.py test_tokenize
test_tokenize
1 test OK.
[25131 refs]

C:\Code\python\PCbuild>python_d ../Lib/test/regrtest.py -uall test_tokenize
test_tokenize
test test_tokenize crashed -- :
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] pysqlite for 2.5?

[Guido van Rossum]

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] 2.5 trunk built for Windows available?

[Georg Brandl]

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

[Python-Dev] Fwd: Python 2.5 update

[Martin Blais]

-- 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

Re: [Python-Dev] xmlrpclib.binary missing?

[Chris AtLee]

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

Re: [Python-Dev] xmlrpclib.binary missing?

[Aahz]

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] pysqlite for 2.5?

[Bill Janssen]

> 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

[Python-Dev] xmlrpclib.binary missing?

[Chris AtLee]

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?

[Georg Brandl]

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"? 
> 
> 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

Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64

[Thomas Heller]

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] PySet API

[Raymond Hettinger]

>> 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] I'm not getting email from SF when assigned a bug/patch

[Guido van Rossum]

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.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I'm not getting email from SF when assigned a bug/patch

[Martin v. Löwis]

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] Win64 AMD64 (aka x64) binaries available64

[Martin v. Löwis]

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] pysqlite for 2.5?

[Georg Brandl]

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"? 
>> 
>> 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] I'm not getting email from SFwhenassignedabug/patch

[Georg Brandl]

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] I'm not getting email from SF when assigned a bug/patch

[Fredrik Lundh]

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.





___
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]

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] alpha problems -- need input

[Thomas Heller]

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 -l 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]

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] Class decorators

[Ian Bicking]

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] I'm not getting email from SF whenassignedabug/patch

[Martin v. Löwis]

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] unicode vs buffer (array) design issue can crash interpreter

[Martin v. Löwis]

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] _xmlplus fixup for 2.5

[Martin v. Löwis]

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] pysqlite for 2.5?

[Martin v. Löwis]

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_ 
> 
> 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] Still looking for volunteer to run Windows buildbot

[Martin v. Löwis]

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?

[Gerhard Häring]

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] pysqlite for 2.5?

[Gerhard Häring]

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]

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"? 
> 
> 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]

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".





___
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

[Eric Frost]

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] PySet API

[Barry Warsaw]

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

Re: [Python-Dev] pysqlite for 2.5?

[Anthony Baxter]

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"? 

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] I'm not getting email from SF whenassignedabug/patch

[Barry Warsaw]

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] I'm not getting email from SFwhenassignedabug/patch

[Fredrik Lundh]

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.





___
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]

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] pysqlite for 2.5?

[M.-A. Lemburg]

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] I'm not getting email from SF whenassignedabug/patch

[Georg Brandl]

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] I'm not getting email from SF whenassignedabug/patch

[Barry Warsaw]

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]

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 when assignedabug/patch

[Barry Warsaw]

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

[Python-Dev] (finally) getting around to killing __private names from stdlib

[Anthony Baxter]

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] _xmlplus fixup for 2.5

[Fredrik Lundh]

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 ?

 



___
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

[Anthony Baxter]

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_ 
>
> 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] pysqlite for 2.5?

[Fredrik Lundh]

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_ 

which reminds me -- is that issue still open ?  martin?  fred?

 



___
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]

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_ 
___
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]

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] Class decorators

[Georg Brandl]

[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?

[Andrew Walkingshaw]

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] pysqlite for 2.5?

[Fredrik Lundh]

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.)

 



___
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]

Bill Janssen wrote:
>> from a user perspective, adding this to the standard library is a no-brainer.
>> the only reason not to add it would be if the release managers don't have
>> time to sort out the build issues.
> 
> I agree with Fredrik here.
> 
> On the package naming issue: using "em" for "email" would be wrong,
> just as "db" for "database" would be wrong.  I might change my mind if
> all stdlib packages were under some toplevel package, like "stdlib".

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.

Thanks,
-- 
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?

[Greg Ewing]

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] Class decorators

[Greg Ewing]

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] Class decorators

[Ben . Young]

[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] building sql queries in python

[Greg Ewing]

Thomas Wouters wrote:
> 
> Have you looked at SqlObject?  (and its associated modules
> sqlobject.sqlbuilder in particular)
> 
> SQLAlchemy (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

[Raymond Hettinger]

[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] Class decorators

[Greg Ewing]

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

[Greg Ewing]

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

--
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 assignedabug/patch

[Wolfgang Langner]

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] Win64 AMD64 (aka x64) binaries available64

[Thomas Heller]

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] building sql queries in python

[Oleg Broytmann]

On Thu, Mar 30, 2006 at 12:09:51AM -0800, Gregory P. Smith wrote:
>  http://www.sqlobject.org/module-sqlobject.sqlbuilder.html

   This automatically generated doc concentrates on the interface instead
of usage. SQLBuilder is really a capable and very pythonic SQL generator.
But it has an issue - it can generate SQL *strings* only for specific
databases - because some SQL constructs are DB-dependent, quoting e.g.
   Some examples are in the __main__ part of sqlbuilder.py:
http://svn.colorstudy.com/SQLObject/trunk/sqlobject/sqlbuilder.py

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I'm not getting email from SF whenassignedabug/patch

[Georg Brandl]

Fredrik Lundh 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 ?
> 
> 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.

Perhaps that Jira is commercial, so it is out of the question for most
open-source Python applications.

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] building sql queries in python

[Thomas Wouters]

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] _bsddb.c ownership

[Thomas Wouters]

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

[Gregory P. Smith]

> 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] I'm not getting email from SF whenassignedabug/patch

[Neal Norwitz]

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