On Mon, 2005-10-10 at 01:47, Calvin Spealman wrote:
Never created for a reason? lumping things together for having the
similar usage semantics, but unrelated purposes, might be something to
avoid and maybe that's why it hasn't happened yet for decorators. If
ever there was a makethreadsafe
On Mon, 2005-10-17 at 21:55, Guido van Rossum wrote:
Let's change the property built-in so that its arguments can be either
functions or strings (or None). If they are functions or None, it
behaves exactly like it always has.
If an argument is a string, it should be a method name, and the
On Mon, 2005-10-17 at 22:24, Guido van Rossum wrote:
IMO, there's not enough advantage in having the property() call before
the functions than after.
Maybe you didn't see the use case that Greg had in mind? He wants to
be able to override the getter and/or setter in a subclass, without
On Mon, 2005-10-17 at 23:46, Guido van Rossum wrote:
But I still like the version with strings better:
x = property('get_x', 'set_x')
This trades two lambdas for two pairs of string quotes; a good deal IMO!
You could of course just do the wrapping in property(). I put that in
quotes
I've had this PEP laying around for quite a few months. It was inspired
by some code we'd written which wanted to be able to get immutable
versions of arbitrary objects. I've finally finished the PEP, uploaded
a sample patch (albeit a bit incomplete), and I'm posting it here to see
if there is
On Fri, 2005-10-28 at 03:53, Thomas Heller wrote:
Can anyone recommend an XEmacs svn plugin to use - I've tried psvn.el
from http://www.xsteve.at/prg/emacs/psvn.el which seems to work?
Yep, that's the one I use, albeit a few revs back from what's up there
now. It's had some performance
On Sat, 2005-10-29 at 12:44, Martin v. Löwis wrote:
What do others think? I personally found those long subject lines
listing all the changed files very ugly and unreadable.
Me too. At work our subject lines contain something like:
Subject: [SVN][reponame] checkin of r12345 -
On Mon, 2005-11-07 at 16:38, Jeremy Hylton wrote:
I think part of the problem is that setup.py has a bunch of heuristics
that are intended to do the right thing without user intervention.
If, on the other hand, the user wants to intervene, because the right
thing is wrong for
On Mon, 2005-11-21 at 12:14 +0100, Armin Rigo wrote:
Still, people generally agree that profile.py, while taking a longer
time overall, gives more meaningful results than hotshot. Now Brett's
student, Floris, extended hotshot to allow custom timers. This is
essential, because it enables
On Fri, 2005-12-09 at 17:19 -0600, Ian Bicking wrote:
I personally feel cls should be used for classmethods, and not
elsewhere. Just like I wouldn't like someone using self outside of
the first argument of instance methods. So class_ still would be a good
spelling elsewhere.
Cool.
On Fri, 2005-12-09 at 16:23 -0800, Robert Brewer wrote:
Barry Warsaw wrote:
Again, I'd say something like: Since your exceptions
will be classes, use the CapWord naming convention for
classes to name your exceptions. It is recommended
that your exception class end in the word Error
On Sun, 2005-12-11 at 11:20 -0500, Jim Fulton wrote:
This seems outdated. My impression, in part from time spent
working with the Python Labs guys, is that it is fine to have public
data sttributes even for non-record types. In fact, I would argue that
any time you would be tempted to
On Fri, 2005-12-09 at 17:19 -0600, Ian Bicking wrote:
I personally feel cls should be used for classmethods, and not
elsewhere. Just like I wouldn't like someone using self outside of
the first argument of instance methods. So class_ still would be a good
spelling elsewhere.
Here's what
On Sun, 2005-12-11 at 16:30 -0600, Ian Bicking wrote:
Potentially it could be added that the whole issue can often be avoided
when an object's methods perform actions instead of returning attributes
of the object. It's a long topic; maybe it could even just be a link,
if someone knows of
On Sun, 2005-12-11 at 15:12 -0800, Brett Cannon wrote:
I remember Barry saying he wanted to start a branch for work on the
next version of the 'email' package. And it is possible more and more
modules developed externally will begin to be included in the stdlib.
Perhaps PEP 2 should be
On Wed, 2005-12-14 at 09:56 -0800, Scott David Daniels wrote:
One good reason for this is that the .pyd's or .so's cannot necessarily
be used from zip files
When you say cannot necessarily, are the situations where they can be
imported from zip files? I thought the answer to that was always
On Wed, 2005-12-14 at 20:21 +0100, Fredrik Lundh wrote:
you could of course add them to the zip file, and automagically extract
them before you start importing things.
Sure (although we don't). I wonder if this is useful functionality for
the core.
-Barry
signature.asc
Description: This
On Tue, 2005-12-13 at 07:26 -0500, Jim Fulton wrote:
I'd add somewhere: If in doubt, chose non-public. You can always change your
mind later.
Added.
We don't use the term private here, since no attribute is really
private in Python (without a generally unnecessary amount of
On Tue, 2005-12-13 at 12:00 -0500, Phillip J. Eby wrote:
In any case, the algorithms involved are near-trivial; the most complex
piece is the processing of complex version specifications like
CherryPy=2.1.0,!=2.1.1-rc2,2.2a into a series of version intervals.
The only outstanding feature
On Wed, 2005-12-14 at 09:08 -0800, Michael Chermside wrote:
Wolfgang writes:
We need a clear style for function and method names
now std lib uses foo_bar sometimes foobar
and sometimes fooBar.
Personally, I prefer fooBar. But I try not to use it in python
code... I try to always use
On Wed, 2005-12-14 at 10:17 -0800, Guido van Rossum wrote:
Actually this (function, method and ivar names) is such a contentious
issue that I think the style guide should explicitly allow all
two/three styles and recommend to be consistent within a class, module
or package.
My own feeling is
I've pushed out a revised PEP 8
http://www.python.org/peps/pep-0008.html
Please review and comment. Thanks everyone for providing an excellent
discussion. Hopefully I have captured our current collective
recommendations. I've also tried to simplify the text, while making it
(somewhat) more
On Wed, 2005-12-14 at 14:10 -0800, Guido van Rossum wrote:
Thanks, Barry! I've made another pass and added a couple more tweaks,
hopefully non-controversial.
Cool thanks Guido. I fixed a couple of small typos.
One question: you made the suggestion that a blank line separate the
last line in
On Wed, 2005-12-14 at 14:14 -0800, Guido van Rossum wrote:
Historically many Python developers use Emacs. Barry I still do.
I think the best way to avoid editor wars is to pick one editor and
stick with it. :-)
Dinosaurs rule! :)
-Barry
signature.asc
Description: This is a digitally
On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote:
The only thing I strongly disagree with is the promotion of javaNaming
to equal footing with python_naming.
Actually, they're not on equal footing atm. I happen to agree with you
though.
-Barry
signature.asc
Description: This is a
On Wed, 2005-12-14 at 17:04 -0800, Guido van Rossum wrote:
One question: you made the suggestion that a blank line separate the
last line in a tqs docstring from its closing tqs. I'm wondering why
that is. Note that python-mode now (or shall we say with the fix I just
made ;) properly
On Wed, 2005-12-14 at 20:09 -0600, Ian Bicking wrote:
I think it's reasonable to loosen the
phrasing a bit -- it's nearly always better to stay consistent with a
package than follow PEP 8 on this point.
I agree, but actually I think there's a wider point to be made. The
worst of all
On Wed, 2005-12-14 at 20:22 -0600, Ian Bicking wrote:
I think the reference to Emacs here is unneeded. Use 4 spaces per
indentation level is sufficient instruction on its own.
Agreed. I've removed all references to Emacs in the PEP.
I think the reference to PEP 263 tests is kind of
On Wed, 2005-12-14 at 18:42 -0800, Guido van Rossum wrote:
Deprecated functions could be listed, too.
I think that's more proper for a separate PEP -- the style guide
shouldn't have to be updated each time something else is deprecated.
+1 to that, although I won't write that PEP. If
On Wed, 2005-12-14 at 20:41 -0800, Guido van Rossum wrote:
On 12/14/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Thu, 2005-12-15 at 11:13 +1100, Dave Cole wrote:
The only thing I strongly disagree with is the promotion of javaNaming
to equal footing with python_naming.
Actually
On Thu, 2005-12-15 at 11:35 -0800, Josiah Carlson wrote:
In regards to naming conventions, I find that CapWords are easier for me
to read and remember as a native speaker of english. I've heard
statements from non-native english speakers that CapWords are hard to
read and/or understand, but
SF patch # 1382163 is a fairly simple patch to expose the Subversion
revision number to Python, both in the Py_GetBuildInfo() text, and in a
new Py_GetBuildNumber() C API function, and via a new sys.build_number
attribute. This number is calculated from the output of svn info at
the top of the
On Thu, 2005-12-15 at 22:13 -0800, Brett Cannon wrote:
+0
It makes it easy to request the revision number from people who submit
patches and bugs. But I also don't find it vital since running ``svn
info .``.
That's really more the point, that you can talk about a specific svn
revision
On Fri, 2005-12-16 at 01:38 -0500, Phillip J. Eby wrote:
FYI, this is not the true revision number; it's only the revision number in
which the directory was last modified, not the latest revision number
within the tree.
Yep, I know. At work, we've gone through many iterations of this,
On Fri, 2005-12-16 at 17:11 -0500, Phillip J. Eby wrote:
It looks like using 'svnversion -c . | cut -f2 -d:' would get the
most-recent committed version, plus the letter M if there are local
changes. That sounds like what we should be using.
That way, a build with local revisions would
On Sat, 2005-12-17 at 23:48 +0100, Martin v. Löwis wrote:
Barry Warsaw wrote:
AFAICT, the reason to use -c is so that changes outside the Python
source tree (i.e. in the sandbox) won't show up in Python's build
number. That's fine although I wouldn't mind leaving off the -c since
you'll
On Sun, 2005-12-18 at 18:58 +0100, Armin Rigo wrote:
On Sat, Dec 17, 2005 at 08:28:17PM -0500, Barry Warsaw wrote:
Done. r41744.
Doesn't appear to work for me: sys.build_number receives the value from
the buildno. Looking at the Makefile, the reason is that I'm building
CPython
On Sun, 2005-12-18 at 19:19 +0100, Martin v. Löwis wrote:
It stopped counting builds on Windows quite some time ago; perhaps it
is best to drop the build number entirely?
I think so, because it doesn't really convey anything useful.
-Barry
signature.asc
Description: This is a digitally
On Sun, 2005-12-18 at 23:48 +0100, Martin v. Löwis wrote:
What does that achieve? It will give you the latest revision at which
getbuildinfo was changed (currently 41744).
Dunno. It's better than nothing I guess.
-Barry
signature.asc
Description: This is a digitally signed message part
On Wed, 2005-12-21 at 20:36 +0100, Fredrik Lundh wrote:
I'm not really interested in optimizing for you, I'm interested in optimizing
for everyone else. They already know HTML. They don't know ReST, and
I doubt they care about it (how many blogs accept ReST for comments?)
Sorry, but HTML
I think we have a fundamental problem with Python-ast.c and
Python-ast.h. These files should not be both auto-generated and checked
into Subversion. The problem is that if you do a make distclean,
these files will get removed and svn stat will give you a ! flag. Of
course, you can svn up to get
On Mon, 2006-01-02 at 15:16 -0800, Neal Norwitz wrote:
The Python-ast.[ch] should probably not be removed by distclean. This
is similar to configure. Would that make you happy? What else would
improve the current situation?
I think it would, without causing bootstrapping issues.
-Barry
On Wed, 2006-01-04 at 22:01 +0100, Reinhold Birkenfeld wrote:
Recently, someone on dclpy posted about an error he got
when he tried to unpack the Python distribution tarball
with Sparc Solaris 9's tar:
tar: directory checksum error
With GNU tar, it worked correctly.
Is this a known
On Thu, 2006-01-05 at 00:36 +0100, Martin v. Löwis wrote:
The portable way would be to check for svnversion in configure, and then
only use it if it was found. You could also check for .svn in configure,
and generate the entire buildno generation.
OTOH, I also think we should get rid of
On Fri, 2006-01-06 at 01:33 +0100, Martin v. Löwis wrote:
As you can see, this is done now. The value appears at the Python
level only for tags, though, because it will be unreliable for the
trunk and for branches.
Cool, thanks. I can chuck my local diffs now. :)
patchlevel.h seems like
On Tue, 2006-01-10 at 00:01 +, Vinay Sajip wrote:
I maintain the logging package, and I will happily review patches and apply
them where I think they're fine. I have accepted many patches to the
package, some via SF and some sent privately, but also rejected a few. For
example, the
On Wed, 2006-01-11 at 07:59 +0100, Thomas Heller wrote:
Another possibility would be to emit a warning when the module (dl or
ctypes, if included) is imported.
warnings.warn(Incorrect usage of this module may crash Python,
RuntimeWarning, stacklevel=2)
BTW, although I'm
On Wed, 2006-01-11 at 14:54 +0100, Thomas Wouters wrote:
On Wed, Jan 11, 2006 at 07:59:50AM -0500, Barry Warsaw wrote:
BTW, although I'm pretty sure the answer is no (at least, I hope it
is), is anyone aware of a situation where the mere importation of a
module can cause Python to crash
On Tue, 2006-01-17 at 15:08 +1100, Andrew Bennetts wrote:
My reaction having read this far was huh?. It took some time (several
seconds) before it occurred to me what you wanted str(5,2) to mean, and why it
should give '101'.
If you'd proposed, say (5).as_binary() == '101', or
On Mon, 2006-01-16 at 20:49 -0800, Bob Ippolito wrote:
The only bases I've ever really had a good use for are 2, 8, 10, and
16. There are currently formatting codes for 8 (o), 10 (d, u), and
16 (x, X). Why not just add a string format code for unsigned
binary? The obvious choice is
On Tue, 2006-01-17 at 19:17 +0100, Thomas Heller wrote:
Building the readline on OS X 10.4 fails, is this known, or am I doing
something wrong?
There are definitely serious issues with readline on OS X 10.4. I've
hit them too but haven't had time to post about it yet. I'm far from an
expert
On Fri, 2006-01-20 at 06:56 +1000, Nick Coghlan wrote:
I'm not aware of anyone that would miss octal literals, but there are plenty
of hardware weenies like me that would find int(DEAD, 16) less convenient
than 0xDEAD.
Although octal literals is handy for things like os.chmod(). Unix
On Jan 18, 2006, at 8:24 AM, Stephen J. Turnbull wrote:
The import of the Ghostscript case is that the FSF considers a
Makefile stanza clearly intended to cause linkage to a GPL library,
even if optional and supplied by the user, to create a work derived
from that library. A GNU
On Jan 21, 2006, at 11:19 AM, Barry Warsaw wrote:
In that case, what I think we ought to do is not add the DP paths
(i.e. /opt/local) to setup.py specifically to get its readline, but
instead to pick up any libraries that happen to be in DP in
preference to those in OSX by default
On Thu, 2006-01-26 at 12:51 +1300, Tony Meyer wrote:
[John J Lee]
But it's a very readable way to write a common operation. Perhaps one
reason the discrepancy you point out doesn't bother me is that
division is
the least-used of the +-*/ arithmetic operations.
Do you have evidence
On Wed, 2006-01-25 at 18:10 -0600, Ian Bicking wrote:
Paths are strings, that's in the PEP.
As an aside, I think it should be specified what (if any) string methods
won't be inherited by Path (or will be specifically disabled by making
them throw some exception). I think .join() and
On Thu, 2006-01-26 at 11:40 +1000, Nick Coghlan wrote:
The main appeal to me of the division operation is that it allows multiple
path elements to be joined on a single line, but the joining method accepts
an
arbitrary number of arguments, which helps with that just as much, and
doesn't
On Wed, 2006-01-25 at 21:02 -0600, Ian Bicking wrote:
ext = '.jpg'
name = fields['name']
image = Path('/images') / name + ext
Here's a good example of why I ultimately don't like __div__. The last
line seems quite non-obvious to me. It's actually jarring enough that I
have to stop
On Wed, 2006-01-25 at 22:30 -0600, Ian Bicking wrote:
IMHO the hierarchy problem is a misdesign of strings; iterating over
strings is usually a bug, not a deliberately used feature. And it's a
particularly annoying bug, leading to weird results.
Agreed. I've written iteration code that
On Sat, 2006-01-28 at 19:46 +0100, Martin v. Löwis wrote:
Barry Warsaw favours Jira as a tracker.
Still do! At at one time the Atlassian folks offered to help us import
the SF tracker data into Jira if we could get a machine readable
(hopefully XML-ish) dump of the current SF tracker data. I
On Mon, 2006-01-30 at 16:44 -0500, Tim Peters wrote:
OTOH, I have no reason to _presume_ that this is their hoped-for
outcome wrt Python, neither to presume that the politics shaping their
tussle with Aladdin are relevant to the PSF. The law is rarely
applied uniformly, in large part because
On Wed, 2006-02-01 at 09:47 -0800, Josiah Carlson wrote:
I hope I'm not the only one who thinks that simple is better than
complex, at least when it comes to numeric constants. Certainly it
would be _convenient_ to express constants in a radix other than decimal,
hexidecimal, or octal, but
On Wed, 2006-02-01 at 11:07 -0800, Josiah Carlson wrote:
In my experience, I've rarely had the opportunity (or misfortune?) to
deal with negative constants, whose exact bit representation I needed to
get just right. For my uses, I find that specifying -0x... or -...
to be sufficient.
I
On Tue, 2006-02-07 at 16:01 -0800, Robert Brewer wrote:
Perhaps, but please keep in mind that the smtpd module uses both, currently,
and would have to be rewritten if either is removed.
Would that really be a huge loss?
-Barry
signature.asc
Description: This is a digitally signed message
On Wed, 2006-02-08 at 10:24 -0800, Robert Brewer wrote:
It'd be a huge loss for the random fellow who needs to write an email
fixup proxy between a broken client and Exim in a couple of hours. ;)
Or the guy who needs to whip together an RFC-compliant minimal SMTP
server to use in unit tests of
On Wed, 2006-02-08 at 11:45 -0800, Keith Dart wrote:
There are other, third-party, SMTP server objects available. You could
always use one of those.
Very true. In fact, Twisted comes to the rescue again here. When I
needed to test Mailman's NNTP integration I could either spend several
I posted a message to the email-sig expressing my desire to change our
module naming scheme to conform to PEP 8. This would entail a bump in
the email version to 3.1, and would be included in Python 2.5. Of
course, the old names would still work, for at least one Python release.
All the
On Feb 9, 2006, at 3:41 AM, Smith wrote:
I'm wondering if it's just foolish consistency (to quote a PEP 8)
that is calling for the dropping of in preference of only !=.
I've used the former since the beginning in everything from basic,
fortran, claris works, excel, gnumeric, and
On Thu, 2006-02-09 at 11:30 -0800, Guido van Rossum wrote:
In the past, the protocol for aqcuiring a PEP number has been to ask
the PEP coordinators (Barry Warsaw and David Goodger) to assign one. I
believe that we could simplify this protocol to avoid necessary
involvement of the PEP
On Thu, 2006-02-09 at 19:10 -0500, Jim Jewett wrote:
Logically, = means the same as or =
does not mean the same as or ; it might just mean that
they aren't comparable. Whether that is a strong enough reason
to remove it is another question.
Visually, == looks very symmetrical and
On Feb 10, 2006, at 3:21 PM, Guido van Rossum wrote:
PEP 351 - freeze protocol. I'm personally -1; I don't like the idea of
freezing arbitrary mutable data structures. Are there champions who
want to argue this?
I have no interest in it any longer, and wouldn't shed a tear if it
were
On Feb 10, 2006, at 5:47 PM, Guido van Rossum wrote:
On 2/10/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Barry Warsaw]like to put email 3.1 in Python 2.5
with the new module naming scheme. The old names will still work,
and all the unit tests pass. Do we need a PEP for that?
+1
I
On Feb 11, 2006, at 3:55 PM, Alex Martelli wrote:
On Feb 10, 2006, at 1:05 PM, Raymond Hettinger wrote:
[Guido van Rossum]
PEP 351 - freeze protocol. I'm personally -1; I don't like the
idea of
freezing arbitrary mutable data structures. Are there champions who
want to argue this?
It
On Mon, 2006-02-13 at 15:44 -0800, Guido van Rossum wrote:
The right way to look at this is, as Phillip says, to consider
conversion between str and bytes as not an encoding but a data type
change *only*.
That sounds right to me too.
-Barry
signature.asc
Description: This is a digitally
On Feb 13, 2006, at 7:29 PM, Guido van Rossum wrote:
There's one property that bytes, str and unicode all share: type(x[0])
== type(x), at least as long as len(x) = 1. This is perhaps the
ultimate test for string-ness.
But not perfect, since of course other containers can contain objects
of
On Feb 14, 2006, at 6:35 AM, Greg Ewing wrote:
Barry Warsaw wrote:
This makes me think I want an unsigned byte type, which b[0] would
return.
Come to think of it, this is something I don't
remember seeing discussed. I've been thinking
that bytes[i] would return an integer
On Tue, 2006-02-14 at 14:37 -0800, Alex Martelli wrote:
What about shorter names, such as 'text' instead of 'opentext' and
'data' instead of 'openbinary'? By eschewing the 'open' prefix we
might make it easy to eventually migrate off it. Maybe text and data
could be two subclasses of file,
On Tue, 2006-02-14 at 15:13 -0800, Guido van Rossum wrote:
So I'm taking that the specific properties you want to model are the
overflow behavior, right? N-bit unsigned is defined as arithmethic mod
2**N; N-bit signed is a bit more tricky to define but similar. These
never overflow but
On Wed, 2006-02-15 at 09:17 -0800, Guido van Rossum wrote:
Regarding open vs. opentext, I'm still not sure. I don't want to
generalize from the openbytes precedent to openstr or openunicode
(especially since the former is wrong in 2.x and the latter is wrong
in 3.0). I'm tempting to hold out
On Wed, 2006-02-15 at 18:29 +0100, M.-A. Lemburg wrote:
Maybe a weird idea, but why not use static methods on the
bytes and str type objects for this ?!
E.g. bytes.openfile(...) and unicode.openfile(...) (in 3.0
renamed to str.openfile())
That's also not a bad idea, but I'd leave off one
On Wed, 2006-02-15 at 00:34 -0800, Brett Cannon wrote:
I personally think we should choose an initial global access API to
the AST as a starting API. I like the sys.ast_transformations idea
since it is simple and gives enough access that whether read-only or
read-write is allowed something
On Tue, 2006-02-14 at 21:24 -0800, Neal Norwitz wrote:
We still need a release manager. No one has heard from Anthony. If
he isn't interested is someone else interested in trying their hand at
it? There are many changes necessary in PEP 101 because since the
last release both python and
On Wed, 2006-02-15 at 19:02 +0100, M.-A. Lemburg wrote:
Anyway, as long as we don't start adding openthis() and openthat()
I guess I'm happy ;-)
Me too! :)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev
On Wed, 2006-02-15 at 14:01 -0500, Jason Orendorff wrote:
Instead of byte literals, how about a classmethod bytes.from_hex(),
which works like this:
# two equivalent things
expected_md5_hash =
bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
expected_md5_hash = bytes([92, 83, 80,
On Wed, 2006-02-15 at 22:07 +0100, M.-A. Lemburg wrote:
Those are not pseudo-encodings, they are regular codecs.
It's a common misunderstanding that codecs are only seen as serving
the purpose of converting between Unicode and strings.
The codec system is deliberately designed to be
On Thu, 2006-02-16 at 01:09 +0100, Fredrik Lundh wrote:
(but will there be a 2.6? isn't it time to start hacking on 3.0?)
We know at least there will never be a 2.10, so I think we still have
time.
-Barry
signature.asc
Description: This is a digitally signed message part
On Sat, 2006-02-18 at 12:53 +0100, Pierre Barbier de Reuille wrote:
Guido Over lunch with Alex Martelli, he proposed that a subclass of
Guido dict with this behavior (but implemented in C) would be a good
Guido addition to the language.
I agree that .setdefault() is a
On Fri, 2006-02-17 at 11:09 -0800, Guido van Rossum wrote:
Thanks for all the constructive feedback. Here are some responses and
a new proposal.
- Yes, I'd like to kill setdefault() in 3.0 if not sooner.
A worthy goal, but not possible unless you want to break existing code.
I don't think
On Fri, 2006-02-17 at 00:43 -0500, Steve Holden wrote:
Fredrik Lundh wrote:
Barry Warsaw wrote:
We know at least there will never be a 2.10, so I think we still have
time.
because there's no way to count to 10 if you only have one digit?
we used to think that back when
On Sun, 2006-02-19 at 23:30 +0900, Stephen J. Turnbull wrote:
M == M.-A. Lemburg [EMAIL PROTECTED] writes:
M * for Unicode codecs the original form is Unicode, the derived
M form is, in most cases, a string
First of all, that's Martin's point!
Second, almost all Americans, a
On Fri, 2006-02-17 at 14:01 +0100, Georg Brandl wrote:
Fredrik Lundh wrote:
Georg Brandl wrote:
as Jim Jewett noted, multifile is supplanted by email as much as mimify
etc.
but it is not marked as deprecated. Should it be deprecated in 2.5?
-0.5 (gratuitous breakage).
I
Guido's on_missing() proposal is pretty good for what it is, but it is
not a replacement for set_default(). The use cases for a derivable,
definition or instantiation time framework is different than the
call-site based decision being made with setdefault(). The difference
is that in the former
On Feb 23, 2006, at 4:41 PM, Thomas Wouters wrote:
On Wed, Feb 22, 2006 at 10:29:08PM -0500, Barry Warsaw wrote:
d.getdefault('foo', list).append('bar')
Anyway, I don't think it's an either/or choice with Guido's subclass.
Instead I think they are different use cases. I would add
On Feb 28, 2006, at 6:26 PM, Fredrik Lundh wrote:
should we perhaps switch to (careful use of) C++ in 3.0 ?
I hope not. It would make life more difficult for embedded/extended
users like ourselves because it would force us to link our
applications as C++ programs. That introduces lots of
On Wed, 2006-03-01 at 11:00 -0800, Talin wrote:
However, I would like to be able to reply to posts in such a way as to
have them appear in the appropriate place in the thread hierarchy. Since
I don't have the original email, I cannot reply to it directly; instead
I have to create a new,
On Fri, 2006-03-03 at 13:06 -0800, Michael Chermside wrote:
I think it's clear that if a method is invoked magically, it ought to have
underscores; if it is invoked directly then it ought not to. next() is
invoked both ways, so the question is which of the following invariants
we would rather
On Wed, 2006-03-01 at 00:17 -0600, Tim Peters wrote:
OK, I tried to set eol-style on all of those. svn refused to change these:
svn: File 'Lib\email\test\data\msg_26.txt' has binary mime type property
Yeah, there's no reason for that, so I've fixed it.
-Barry
signature.asc
Description:
On Fri, 2006-03-03 at 23:43 -0500, Barry Warsaw wrote:
On Wed, 2006-03-01 at 00:17 -0600, Tim Peters wrote:
OK, I tried to set eol-style on all of those. svn refused to change these:
svn: File 'Lib\email\test\data\msg_26.txt' has binary mime type property
Yeah, there's no reason
On Mon, 2006-03-06 at 14:26 -0500, Tim Peters wrote:
[Ben Chelf [EMAIL PROTECTED]]
...
I'd ask that if you are interested in really digging into the results a bit
further for your project, please have a couple of core maintainers (or
group nominated individuals) reach out to me to request
There are two patches on SF to add a couple of features to the gc
module. Skip wrote one (which I reviewed) and I wrote the other.
Neither is earth shattering, but they're helpful when debugging gc
issues.
Skips adds some timing output when DEBUG_STATS is set:
101 - 200 of 2552 matches
Mail list logo
