On Thu, Aug 12, 2010 at 6:18 AM, Steve Holden wrote:
> Didn't we have this discussion when per-user libraries came up?
> Shouldn't we be using a subdirectory of that location? We ruin the risk
> of Python becoming distributed so finely it becomes impossible to change
> things, what with per-user l
On Thu, Aug 12, 2010 at 11:02 AM, Alexander Belopolsky
wrote:
> I remember there was an idea somewhere to replace "patch" tag with a
> check-list with boxes for code, tests, and docs. I think that would
> be better than "unit test needed" stage.
Are you suggesting check boxes for what's needed,
On Fri, Aug 13, 2010 at 11:57 AM, Barry Warsaw wrote:
> I've missed most of this discussion while on vacation, but if ~/.local is
> supposed to mirror /usr/local, then wouldn't a logical place for per-user
> configuration files be ~/.local/etc/whatever.cfg?
Maybe it is; I'd hope so.
The fd.o spe
On Fri, Aug 13, 2010 at 3:21 PM, John Arbash Meinel
wrote:
> I don't know what the specific issue is here, but adding entries to
> sys.path makes startup time *significantly* slower.
>
> I happen to use easy_install since Windows doesn't have its own package
> manager. Unfortunately the default of
On Tue, Sep 7, 2010 at 10:38 AM, Antoine Pitrou wrote:
> Could push notification be added for the benchmarks repo?
> I think the python-checkins list would be an appropriate recipient for
> the e-mails (the repo has a low activity).
+1
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in
On Fri, Sep 10, 2010 at 4:32 PM, Georg Brandl wrote:
> IMO this runs contrary to the decision we made when DeprecationWarnings were
> made silent by default: it spews messages not only at developers, but also at
> users, who don't need it and probably are going to be quite confused by it,
Agreed;
2010/9/18 "Martin v. Löwis" :
> Any other opinions?
-1 from me as well; I see no reason to encourage use of bad metadata,
given mechanisms to get correct metadata exist (running "setup.py
egg_info", as others have pointed out). I understand there are
perceived uses for such data, but it's just as
On Wed, Sep 22, 2010 at 10:38 PM, Brett Cannon wrote:
> the first thing on the agenda is a complete rewrite of the developer
> docs and moving them into the Doc/ directory
I'd like to know why you think moving the developer docs into the
CPython tree makes sense.
My own thought here is that they
On Thu, Sep 23, 2010 at 2:40 AM, Georg Brandl wrote:
> That's right. It is true that it isn't branch-specific information,
> and that does cause a little bit of irritation for me too, but neither
> is Misc/developers.txt or Misc/maintainers.rst.
Agreed. I'd rather those were elsewhere as well,
On Wed, Sep 29, 2010 at 5:41 PM, Daniel Stutzbach
wrote:
> Obviously, it would not be possible to write hooks that reject changesets
Of course, this is one of the more interesting ways to use hooks.
Since there's no current expectation that running our own will be a
problem, why don't we convert
On Wed, Sep 29, 2010 at 5:57 PM, Nick Coghlan wrote:
> Would it be possible to sync up the reitveld issue numbers with the
> roundup ones if you did that? Or would the fact that a single issue
> can have multiple attached patches prevent that?
Another quirk would be that often several pieces are
On Fri, Oct 1, 2010 at 12:31 PM, Barry Warsaw wrote:
> I should note one other thing, in reference to my previous posting about
> reviews. Launchpad does have a backdoor for getting changes in without
> formal review. It's called "rubber stamping" and shows up in commit messages,
This makes a l
On Fri, Oct 8, 2010 at 7:24 AM, Dirkjan Ochtman wrote:
> It doesn't seem very nice to have a version in the script. Can we just
> call it distutils? Or py-dist?
If we go this route, then
- "make altinstall" should include the version number in the name of *any*
scripts it installs.
- "make in
On Fri, Oct 8, 2010 at 9:22 AM, Tarek Ziadé wrote:
> pkg_manager ?
1. Underscores are evil. Don't do that.
2. Mixed shortened + written-out names are just nasty.
> Mmm.. setup.py is gone in D2, and setup.py will be the marker of d1.
Did we finally decide it could be done without setup.py enti
On Tue, Oct 26, 2010 at 4:46 PM, Michael Foord
wrote:
> I find the big-ball-of-mud style development, where everything lives inside
> huge monolithic modules, very painful. I also think that it is an extremely
> bad example for new developers.
Gadzooks, Michael! Something else we agree on. 2000
On Tue, Nov 2, 2010 at 12:37 PM, Jacob Kaplan-Moss wrote:
> Hopefully I'm still allowed to use Python.
Definitely! Python's a great place to learn about all these things. :-)
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
__
On Tue, Nov 2, 2010 at 8:47 PM, Ben Finney wrote:
> I would say that names without a single leading underscore are part of
> the public API, whether documented or not.
I don't recall this ever being the standard library's policy. There are
many modules using leading underscores as hints, and man
On Thu, Nov 11, 2010 at 8:23 AM, Alexander Belopolsky
wrote:
> I don't dispute that these are *the* rules, but my question was
> whether it is ok to break them in specific cases such as
> trace.rx_blank. If not, how can we deprecate trace.rx_blank which is
> a regex constant?
Since trace is docu
On Fri, Nov 12, 2010 at 3:57 AM, georg.brandl
wrote in a commit:
> Add a deprecated-removed directive that allows to give the version of removal
> for deprecations.
This sounds pretty general-purpose rather than Python-specific. Any
chance this will move into Sphinx? I know a few projects that
On Tue, Nov 16, 2010 at 4:31 PM, Ben Finney wrote:
> I don't know about Guido, but I'd be -1 on suggestions to add more
> normative information to PEP 7, PEP 8, PEP 257, or any other established
> style guide PEP. I certainly don't want to have to keep going back to
> the same documents frequently
2010/11/17 Michael Foord :
> So -1 on splitting Python development style guide into multiple documents.
I don't think that the publicness or API stability promises of the
standard library are part of a style guide. They're an essential part
of the library documentation. They aren't a guide for 3
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan wrote:
> The library documentation is *not* the right place for quibbling about
> what constitutes a public API when using other means than the library
> documentation to find APIs to call.
Quibbling can happen on the mailing list, where it can be ign
On Wed, Nov 17, 2010 at 4:22 PM, Georg Brandl wrote:
> So it comes down again to what we'd like __all__ to mean foremost:
> public API, or just a list for "import *"?
It is and has been since its inception *the* list for "import *".
Any additional meaning will have to accommodate that usage as w
On Thu, Nov 18, 2010 at 6:41 AM, Michael Foord
wrote:
> Along with the others +1
I agree with keeping these distinct and orthogonal as well.
> What is more important is that we have a clearly stated policy for new
> modules and adding names to existing modules so that we don't have to repeat
> t
On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou wrote:
> Enumerations aren't a type at all (they have no distinguishing
> property).
In any given language, this may be true, or not. Whether they should
be distinct in Python is core to the current discussion.
>From a backward-compatibility pers
On Tue, Nov 23, 2010 at 9:35 PM, Raymond Hettinger
wrote:
> The least worst option is to do nothing at all.
For the standard library, I agree.
There are enough variants that are needed/desired in different
contexts, and there isn't a single clear winner. Nor is there any
compelling reason to ha
On Tuesday 11 July 2006 14:12, Alexander Belopolsky wrote:
> Also __new__ and __init__ method docstrings is the natural place to
> put set-up code.
Maybe, if all the tests required the same setup code. That's often not the
case.
-Fred
--
Fred L. Drake, Jr.
Zope Corporation
On Tuesday 11 July 2006 14:37, Alexander Belopolsky wrote:
> That's true, but you cannot test an object method without creating the
> object first.
True. How the object is created can vary; if the creation affects the
expected behavior in any way, you'll need be careful about how the
constr
2010/12/5 Łukasz Langa :
> On a related note, if you're sure logging users don't use any interpolation,
> you can also use SafeConfigParser(interpolation=None) so then all values
> become raw by default (e.g. people can use Python string formatting
> directives, % signs etc.). We can discuss this l
On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger
wrote:
> We really ought to stop with the SafeFoo naming convention.
> It is only descriptive to the person who wrote the class or function,
> not to the user who will immediately wonder, "safe from what?"
Safe from bad vampire movies, of course!
On Mon, Dec 6, 2010 at 4:02 PM, Raymond Hettinger
wrote:
> IIRC, pprint has a safe_repr() and string.Template has safe_substitute()
> and pydoc has a safe import.
pprint.saferepr
Ok, this one's my fault as well. Probably should just be named repr.
string.Template.safe_substitute
Agree o
On Wed, Dec 8, 2010 at 8:19 AM, Paul Moore wrote:
> But you don't because the library developer added a NullHandler which
> you have to switch off!!!
I'm suspecting there's misunderstanding on this point.
If I have a logger "myns.mypackage" for my library, and register a
NullHandler for that, th
On Wed, Dec 8, 2010 at 9:27 AM, Antoine Pitrou wrote:
> The thing is, they don't *want* to configure them, but you force them
> to do some configuration if they don't want error messages to be
> silenced.
As I tried to explain earlier, a NullHandler doesn't silence anything
except the message abo
On Tue, Dec 14, 2010 at 6:24 AM, Steven D'Aprano wrote:
> The good thing about that idea is that maintenance of buggy.py will be so
> simple!
It's self-describing, and needs no further documentation. :-)
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
__
On Wed, Dec 15, 2010 at 1:39 PM, Antoine Pitrou wrote:
> I would like to remove HTTP 0.9 support from http.client and
> http.server.
+1
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
___
Python-Dev mailing list
On Thu, Dec 16, 2010 at 10:52 AM, André Malo wrote:
> I'd vote for removing it from the client code and keeping it in the server.
If it must be maintained anywhere, it should be in the client,
according to the basic principle of "accept what you can, generate
carefully."
Python.org's HTTP/0.9 re
On Thu, Dec 16, 2010 at 1:30 PM, wrote:
> I doubt this makes a difference to the point being discussed, but it
> _could_. I suggest performing your tests with telnet, instead.
I received similar results using telnet earlier today.
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my
On Mon, Jan 24, 2011 at 2:04 PM, Raymond Hettinger
wrote:
> ISTM, that if we're going to use python packages as "namespace containers" for
> categorizing modules, then the top level __init__ namespace should be left
> empty.
This is only an issue if the separate components are distributed
separa
On Mon, Jan 24, 2011 at 2:46 PM, Raymond Hettinger
wrote:
> P.S. I've discussed this with Michael and his preference is against
> going back to the Py3.1 style where the tests were under Lib/test. He
> thinks the current tree makes it easier to sync with Py2.7 and the
> unittest2 third-party mod
On Mon, Jan 24, 2011 at 4:59 PM, Tres Seaver wrote:
> It might matter if we want to enable third-party package installation
> into a namespace also used by the stdlib: ISTR that the 'xml' package
> had such installs at one point.
Almost, but not quite.
The xml package at one point allowed itsel
On Thu, Jan 27, 2011 at 3:38 PM, Brett Cannon wrote:
> Linking to the 2.7.0 release page seems off since it is
> out of date, but linking to 2.7.1 also seems silly as that will become
> out of date as the newest release of Python 2.7 at some point as well.
I'd love to see something like this as w
On Fri, Mar 4, 2011 at 10:59 AM, wrote:
> Something to consider here is how this will interact with Python files which
> are _not_ modules. I'm a little uneasy about having sys.modules["trial"]
> refer to the module defined by /usr/bin/trial.
I've long held the position that modules and scripts
On Fri, Mar 4, 2011 at 12:35 PM, Michael Foord
wrote:
> That (below) is not distutils it is setuptools. distutils just uses
> `scripts=[...]`, which annoyingly *doesn't* work with setuptools.
Right; distutils scripts are just sad.
OTOH, entry-point based scripts are something setuptools got very
On Sat, Mar 5, 2011 at 3:08 AM, Toshio Kuratomi wrote:
> Some of them can be annoying as hell when dealing with a system that also
> installs multiple versions of a module. But one could argue that's the
> fault of setuptools' version handling rather than the entry-points
> handling.
Agreed; I d
On Wed, Mar 16, 2011 at 12:03 AM, Senthil Kumaran wrote:
> A new function, which can given this behavior is also a good idea.
I'm strongly in favor of this approach. I know we've been bitten by
changes made in the past, and have had to introduce Python-version
specific handling. (I don't have t
On Tue, Mar 22, 2011 at 10:25 AM, Barry Warsaw wrote:
> I'm curious: what are the benefits of the Mercurial model?
If we're all left confused and unable to use the tools to change the
software, we won't break things. This is good. :-)
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in
On Wed, Mar 30, 2011 at 10:08 PM, Terry Reedy wrote:
> Yes, there is a good reason why database records are routinely displayed in
> labeled and located fields rather than in variable length natural language
> sentences with a monochrome font. Form letters, of course, are an exception.
Yep.
Whil
On Fri, Apr 15, 2011 at 8:59 AM, Antoine Pitrou wrote:
> Relying on a vendor distribution (such as a Linux distro, or
> ActiveState) is hopefully enough to get these security updates in time
> without patching anything by hand. I don't think many people compile
> Python for production use, but man
On Sun, Apr 17, 2011 at 7:48 AM, Antoine Pitrou wrote:
> A separate announcement channel (mailing-list or newsgroup) would be better,
> where people can subscribe knowing they will only get a couple of e-mails a
> year.
Sounds like python-announce to me, with a matching entry on the front
of www.
On Mon, Apr 25, 2011 at 8:04 AM, haael wrote:
> Sorry if I am asking the obvious, but why are the aliases of set types not
> included in the 'types' module? I thought for a moment that they are just
> classes, but no, they introduce themselves as built-in types, just like any
> other standard Pyth
On Thu, Apr 28, 2011 at 10:37 AM, Barry Warsaw wrote:
> I would agree. Use asserts for "this can't possibly happen "
> conditions.
Maybe we should rename "assert" to "wink", just to be clear on the usage. :-)
-Fred
--
Fred L. Drake, Jr.
"Give me the luxuries of life and I will willing
On Tue, May 10, 2011 at 6:38 PM, Steven D'Aprano wrote:
> I don't know why it was thought necessary to distinguish between them in the
> first place.
New users almost constantly expressed confusion by NameError when the name
was clearly bound at global scope, and a subsequent assignment caused it
2011/5/23 Łukasz Langa :
> The new Ubuntu already ships with Python 3.2.
Uptake on Ubuntu 11.04 will take longer than 10.10 uptake, given the
reliability issues and the reaction to the new user interface.
That's not to say it won't be significant, but the strength of the
indicator may be less sig
On Mon, May 23, 2011 at 10:40 AM, Barry Warsaw wrote:
> You're not required to run the default desktop (Unity) of course. There are
> several options out of the box, including the classic desktop and Unity 2D,
> and there are a wide range of supported derivatives of Ubuntu offering
> additional d
Egads.
Back when I wrote
"Members and methods" should just be "attributes".
I used quotes to specifically indicate that this applied to the phrase
"members and methods", not their separate use. I guess I wasn't obvious
enough.
The general & Python-historical uses of "members" is unfortunat
On Tue, Jun 28, 2011 at 2:33 AM, Nick Coghlan wrote:
> The two terms I've got out of this thread are "callable attributes"
> (instance/static/class methods, etc) and "data attributes" (everything
> else). Both seem reasonable to me, creating two largely disjoint sets
> that together cover all the
On Tue, Jun 28, 2011 at 6:54 AM, Michael Foord
wrote:
> Added to which there are other descriptors, notably property, that are not
> directly callable but are not provided as normal "data attributes" (although
> the access syntax is the same). Properties are much closer to methods as
> they are im
I vaguely recall some discussion about removing hotshot in favor of a
better maintained profiler that has better thread support as well.
Does anyone remember the decision? I don't see anything about it in
PEP 4 or the Python 3000 PEPs I checked.
-Fred
--
Fred
ru, or even regular user), but it's important to realize that the
pain of the specialness isn't limited. :-)
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
self):
return 42
@property.set
def attribute(self, value):
self._ignored = value
@property.delete
def attribute(self):
pass
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http:
d, self).attribute
I doubt that's all that hard to achieve, at least for a known
property type. To support descriptors of completely different types,
the syntax from the first example may be required unless some other
crutch is added.
-Fred
--
Fred Drake
__
On Nov 1, 2007, at 9:18 PM, Fred Drake wrote:
Thanks! Of all the proposals that have been presented, I still like
that the best.
I've attached a quick hack of an implementation, just to play with it
and see how it feels. Here's an example use:
from property import property
nPython, and PyPy.
That seems a pretty good reason to me.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
rtin's right: there's no value to embedding the logic of auto-
detection into the codec. A function somewhere in the xml package is
all that's warranted.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
est of the editor implementation),
but the same re-encoding issue applies as well.
Simply, it's sometimes desired to know the encoding for purposes that
don't require immediate decoding. A function would be quite handing
in these cases.
-Fred
--
Fred Drake
from the XML
specification should be in the xml package (somewhere). Determining
that the file is an XML file is separate.
I doubt this really makes sense in os.path.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.
27;s going on.
+1 for __builtin_namespace__.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
#x27;re going to pick something reasonable in
spite of our yammering.
+1 for a module named "builtin", or something similarly obscure.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
I
certainly don't view it as interesting in it's own right.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opti
.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
g.python) since the promise has been there for so long.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
I see no need to
duplicate that.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
er and htmllib
(regardless of names); a single capable interface should be provided.
But that's a separate discussion.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Jan 8, 2008, at 7:53 PM, Neal Becker wrote:
> Note also that mercurial has demandimport
> http://www.selenic.com/mercurial/wiki/
Let's not forget zope.deferredimport:
http://pypi.python.org/pypi/zope.deferredimport
-Fred
--
quickly. Sorry!
The URL I posted may be somewhat better for most users, though.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
nly ~/.local/share/ in
that case. Anything beyond that is grass-roots, and still pretty
obscure.
That said, I think extending usage of ~/.local/ is fine for things
that aren't supposed to be edited or directly used by users. ~/.local/
bin/ seems suspect.
probably insane.
This kind of thing would be less of a problem if the standard library
were smaller, and the email package only available separately. It's
also why some of us want a smaller standard library.
-Fred
--
Fred Drake
ackages have been uploaded to python.org.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
acker's tickets for
> posterity. :)
>
> PEP: -1
> tracker: +1
I agree with Jeroen completely on this. Using a PEP for this is just
plain silly.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://
On Feb 26, 2008, at 5:04 PM, Brett Cannon wrote:
> Or we can get rid of bsddb and not have the problem anymore. =)
+1 for fewer problems. :)
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
guments to function
‘setpgrp’
make: *** [Modules/posixmodule.o] Error 1
I can only presume I'm doing something wrong at this point, since I
don't consider myself a Mac OS X developer.
-Fred
--
Fred Drake
___
Python-Dev mailing li
On Mar 2, 2008, at 7:43 PM, Fred Drake wrote:
> 2.4.5 won't build for me from the svn checkout on Mac OS X 10.5.2:
Neither does 2.3.7 now that I've tried that:
gcc -u __dummy -u _PyMac_Error -framework System -framework
CoreServices -framework Foundation
ur
2.4.4 on Mac OS X 10.4.x.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
makes sense to worry about at too detailed a level.
Common sense, knowledge of the interpreter, and experience are often
more valuable the easily-outdated documentation.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.
SourceForge", not that he invented Trove. My understanding is that he
did start the efforts to define the Trove classifiers as part of a
larger effort that never panned out, but that defining the classifiers
was not a solo effort.
-F
deprecations, not recommended for new test code.
+1 !
This kind of information, once known, should be included in all
maintained versions of the documentation so that users can build good
coding habits, or have more time to adjust existing code.
-Fr
ls config
locations) in order to enable per-user installation.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
my note
that my preferred approach would be that there's no default at all;
the location would have to be specified explicitly. Whether on the
command line or in the distutils configuration doesn't matter, but
explicitness should be required.
On May 10, 2008, at 11:49 PM, Guido van Rossum wrote:
Works for me. The other thing I always use from cgi is escape() --
will that be available somewhere else too?
xml.sax.saxutils.escape() would be an appropriate replacement, though
the location is a little funky.
-Fred
--
Fred Drake
all cases.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
's
been fixed in Subversion. :-)
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
xy does support subclassing.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ride on top of HTTP are a different
beast.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
o be used with
pickle within the test as well.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
code in this case.
I think it should be fixed for 2.5 as well, myself.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
t's what I need.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
a happier version.
I think this is worth considering. I vaguely recall that the bsddb
module was maintained before it was incorporated into the core Python
release.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@pytho
e terribly difficult.
It's also entirely possible that the API isn't interesting if you
don't support existing databases, for many applications.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
ms, though
Python 2.5 isn't "officially" supported (whatever that means).
I think current versions of Zope 2 work with Python 2.5 as well.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
101 - 200 of 240 matches
Mail list logo
