Anthony> All naming in the stdlib is adhoc by it's nature. We choose a
Anthony> name, and then that's it's name. I'm pretty happy with either
Anthony> 'db.sqlite' or 'database.sqlite', really.
Let's slow down here. If we are really going to start putting together a
package infrastruc
I just thought of a possible name for the
Python package repository. We could call
it the PIPE - Python Index of Packages
and Extensions.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Chri
At 08:00 PM 3/29/2006 -0500, Jack Diederich wrote:
>A function decorator takes a function as an argument and returns something
>(probably a function and maybe even the very same function).
So would class decorators.
>This is exactly what class decorators should do or we should call them
>somethi
Bill Janssen wrote:
> "db" and "em" are too short to be useful context-free abbreviations,
There's a big difference between "db" and "em": "db" is
an extremely well-known abbreviation, whereas "em" isn't.
At the top level of a reorganised package namespace, I
don't think it would be out of place
Greg> There's a big difference between "db" and "em": "db" is an
Greg> extremely well-known abbreviation, whereas "em" isn't.
Unless you're a typesetter or a TeX hound... :-)
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
Phillip J. Eby wrote:
> My comment above was only about readable *placement* of the decorators, not
> the actual syntax.
The placement is part of the syntax...
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridia
Barry Warsaw wrote:
> On Wed, 2006-03-29 at 16:29 -0500, Raymond Hettinger wrote:
>
>>The story is different for PySet_Update(). Defining it now could get in the
>>way
>>of possible future development for the module (the function may end-up taking
>>a
>>variable length argument list instead o
Jack Diederich wrote:
> Using metaclasses also required gross hacks like checking
> for a 'DO_NOT_REGISTER' member for subclasses that wanted to inherit from
> a class that had a Register metaclass but didn't want to be registered.
I've just done something like this myself in the last
few days, a
[EMAIL PROTECTED] wrote:
> The powers-that-be didn't want to support
> another database server (we already have Sybase) and didn't want our group's
> experimental data "polluting" the production database, so the folks who
> wanted it went the SQLite/pysqlite route. They were immediately bitten by
[EMAIL PROTECTED] wrote:
> If I want to install Object Craft's Sybase wrapper the
> logical place for it seems like stdlib.db.sybase. But that's not right
> because the Sybase module's not part of the stdlib. Okay, it belongs in
> site.db.sybase. But now we have two different db packages and th
On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
>import db where db.stdlib == True and db.language == "SQL" \
> and db.interface == "DBAPI2.0"
While we're at it, we could spell import "select". :-)
-Fred
--
Fred L. Drake, Jr.
__
On Thursday 30 March 2006 12:07, [EMAIL PROTECTED] wrote:
> To many people "SQL" in the name implies "big databases". I know
> from personal experience at work. The powers-that-be didn't want
> to support another database server (we already have Sybase) and
> didn't want our group's experimental
Phillip J. Eby wrote:
> the readability of @decorators on the outside of a class tends
> to suck as the number of decorators and arguments increases.
So do decorators outside a function.
> What's more, I haven't seen anybody posting any counterexamples to show
> that it doesn't suck for common
On Thursday 30 March 2006 12:15, [EMAIL PROTECTED] wrote:
> Someone was throwing around names like db.sqlite as the place to
> install pysqlite.
Dunno who originally suggested it, but the theory was that there's
some issue with toplevel library namespace pollution. I'm not too
stressed out one
[EMAIL PROTECTED] wrote:
> Greg> There's a big difference between "db" and "em": "db" is an
> Greg> extremely well-known abbreviation, whereas "em" isn't.
>
> Unless you're a typesetter or a TeX hound... :-)
Good point! Still, the fact remains that it's
not a well-known abbreviation for *
Fred L. Drake, Jr. wrote:
> On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
> >import db where db.stdlib == True and db.language == "SQL" \
> > and db.interface == "DBAPI2.0"
>
> While we're at it, we could spell import "select". :-)
Getting off on a tangent here, but I would act
On Mar 27, 2006, at 7:20 AM, Raymond Hettinger wrote:
> Why don't we expose _PySet_Next() for Barry and leave it out of the
> public API
> for everyone else.
There are precedents for adding some functionality to the C API but
not documenting it to ensure "non advanced users" don't get hurt -
Hello,
> I think short names are more more consistent with the existing naming in
> the standard library.
>
> +1 on db.sqlite from me.
same for me +1 on db.sqlite
> db.sql.sqlite is another possibility, if adding something like Durus or
> ZODB in the same top-level namespace could be considered
[promted by Phillip Eby's post, but not in response so content snipped]
I think we both want class decorators as a more fine grained substitute
for __metaclass__ (fine grained as in declared per-class-instance instead
of this-class-and-all-its-children). I can think of three ways class
decorators
[Raymond Hettinger]
> > Barry, go ahead with PySet_Clear().
[Barry]
Cool thanks. I think we've also compromised on _PySet_Next(), correct?
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
i
On 3/29/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Tim Hochberg wrote:
>
> > Still, perhaps for Py3K it's worth considering
> > if PyNumber_InplaceAdd should only call __iadd__ and __add__, not
> > __radd__. Thus giving the target object complete control during inplace
> > adds.
>
> That's probabl
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/
On Wed, Mar 08, 2006 at 03:03:48AM +0100, Thomas Wouters wrote:
> On 3/7/06, "Martin v. L??wis" <[EMAIL PROTECTED]> wrote:
> >
> > Thomas Wouters wrote:
> > > Who 'owns' Modules/_bsddb.c, if anyone?
> >
> > It's a fork of pybsddb, originally contributed by Gregory Smith (*).
> > For all practical p
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.
If it makes everyone happy, I shouldn't be in the way. Of cour
Brett Cannon wrote:
> All of them are for function parameters of function pointers (``void
> (*fn)(void)`` and such) when used in both function prototypes and
> function declarations. Do we fix these ourselves, or do we report
> them to the libffi maintainers (or are whom)?
If you don't have writ
On Sat, Mar 11, 2006 at 07:08:14PM +0100, Thomas Heller wrote:
> Martin v. L?wis wrote:
> > Josiah Carlson told me had has given up getting a Windows
> > buildbot running, because every time he installed VS.NET
> > on his machine, the installation would immediately crash.
> >
> > So if anybody wan
Neal Norwitz wrote:
> The question is how to fix these. test_float and test_struct fail due
> to a Floating Point Exception signal (SIGFPE).
I would hope that there is some way to control the floating point error
mode of the CPU (*). Changing it would be one option; Tim hopefully can
tell us whet
On Sun, Mar 12, 2006 at 06:48:13PM -0500, Tim Peters wrote:
> [Trent]
> > :)
> > Did you apply the Berkeley DB patches to your db-4.2.52 sources?
>
> Ah, _which_ patches? As with my buildbot Wiki page, I write down
> everything I do if there's a good chance I may need to do it again.
> So, e.g.,
Gregory P. Smith wrote:
> On Sat, Mar 11, 2006 at 07:08:14PM +0100, Thomas Heller wrote:
>> Martin v. L?wis wrote:
>>> Josiah Carlson told me had has given up getting a Windows
>>> buildbot running, because every time he installed VS.NET
>>> on his machine, the installation would immediately crash.
At 03:09 PM 3/30/2006 +1200, Greg Ewing wrote:
>Well, here's how my use case would look if I had
>class decorators:
>
>@IOClass
>class MyClass:
> ...
>
>Does that count? My decorator wouldn't need any
>arguments, because it looks inside the class for
>all the information it needs. [1]
On 3/29/06, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>
> This is an ideal job for VMWare on an existing linux build machine if
> someone can ante up a win xp and msvc++ license to the cause.
It probably isn't great from a practical point of view if you wanted
to run buildbot for both the server
At 03:21 PM 3/30/2006 +1200, Greg Ewing wrote:
>Fred L. Drake, Jr. wrote:
> > On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
> > >import db where db.stdlib == True and db.language == "SQL" \
> > > and db.interface == "DBAPI2.0"
> >
> > While we're at it, we could spell import "sele
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,
At 11:09 PM 3/29/2006 -0500, Jack Diederich wrote:
>I think we both want class decorators as a more fine grained substitute
>for __metaclass__ (fine grained as in declared per-class-instance instead
>of this-class-and-all-its-children). I can think of three ways class
>decorators are used:
>
>1) r
> 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.
>
> --
>
Hi Tim,
On Wed, Mar 29, 2006 at 08:45:10AM -0700, Tim Hochberg wrote:
> Ouch. Assuming the same path is followed with tuples, I think that this
> means the following behaviour will continue:
>
> >>> t = (1,2,3)
> >>> a = array([4,5,6])
> >>> t += a
> >>> t
> array([5, 7, 9])
I fell into the
On 3/29/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
> I'll just point out that Atlassian has offered us free hosting for a
> Jira/Confluence solution (plus svn and other stuff we may or may not
> want). I personally support this option, but I know (and accept!) that
> there are differing opinion
On Wed, Mar 29, 2006 at 03:35:48PM +0200, Gerhard H?ring wrote:
> Barry Warsaw wrote:
> > On Wed, 2006-03-29 at 19:47 +1100, Anthony Baxter wrote:
> >
> >>My only concern about this is that it wouldn't be possible for other
> >>authors to provide 3rd party packages as (for instance) db.mysqldb
>
Greg Ewing wrote:
> Firebird could be a solution to this. It can be
> used in a mode that doesn't need a server, and it
> has no trouble at all with concurrency or large
> amounts of data that I know of.
so a library that doesn't support multiple independent readers/writers on
a single file at al
On Wed, Mar 29, 2006 at 11:47:10PM +0200, Thomas Wouters wrote:
> Con:
> > * Competing Python wrappers exist
> > * SQLite itself is updated frequently, let alone the wrappers
> > * Build integration risks unknown, possible delay of 2.5?
> > * Another external library to track and maybe have emergen
Hi Tim,
Oups, sorry. I only just realized my mistake and the meaning of your
message.
On Thu, Mar 30, 2006 at 09:27:02AM +0200, Armin Rigo wrote:
> >>> t = (1,2,3)
> >>> t += [4,5,6]
> TypeError: can only concatenate tuple (not "list") to tuple
>
> >>> t += array([4,5,6])
>
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
101 - 142 of 142 matches
Mail list logo
