On Sat, 2005-09-03 at 22:08, Nick Coghlan wrote:
> > See a (very quick and very dirty ;) strawman that I just posted to the
> > wiki. I think this has some interesting semantics, including the
> > ability to control the separator inline in a C++-like fashion. The
> > writef() version also accept
On Sun, 2005-09-04 at 11:59, Guido van Rossum wrote:
> I agree that those are strong arguments, so please hear me out.
Thanks Guido, I think your arguments are powerful too.
-Barry
signature.asc
Description: This is a digitally signed message part
_
On Sun, 2005-09-04 at 22:06, James Y Knight wrote:
> No, we certainly don't /need/ printf(), as is well proven by its
> current absence. Having the operation of printing and the operation
> of string formatting be separated is good, because it means you can
> easily do either one without the
On Sun, 2005-09-04 at 22:32, Guido van Rossum wrote:
> Right. I just have one additional suggestion for the logging package
> (not sure if it should apply to printf as well): if there's a problem
> with the format operator, fall back to printing the format string
> followed by the argument values
On Mon, 2005-09-05 at 12:07, Antoine Pitrou wrote:
> Uh, what about internationalization (i18n) ?
> In i18n you can't avoid the need for parameterized strings.
> For example I want to write :
> _("The file '%s' is read only") % filename
> not :
> _("The file") + " '" + filename + "' "
On Mon, 2005-09-05 at 14:10, François Pinard wrote:
> "The file %(filename)s in directory %(dir)s is read only" % vars()
>
> is already usable. The need being already filled without Template
> strings, it could hardly be presented as a motivation for them. :-)
Except that IME, %(var)s is an e
On Mon, 2005-09-05 at 20:52, Guido van Rossum wrote:
> We could decide not to provide (b) directly, since it is easily
> reduced to (c) using an appropriate format string ("%s" times the
> number of arguments). But I expect that use case (b) is pretty
> important, and not everyone likes having to
On Tue, 2005-09-06 at 00:56, Guido van Rossum wrote:
> On 9/5/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > Eliminating the newline argument from print() would reduce the number of
> > reserved keyword arguments in my strawman by half. Maybe we could even
> > ren
On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote:
> But print-ng looks
> like becoming the OOWTDI for a lot of applications. IMO it's just too
> early to give up on print-ng becoming the one obvious way to do it for
> a lot of i18n apps, too.
+1. I have a gut feeling that we can make it e
On Wed, 2005-09-07 at 08:55, Nick Coghlan wrote:
> The leading 'p' (for 'positional') is necessary to get around the fact that
> $1
> is currently an illegal identifier in a Template
That should be fixable. Ideally, $1 is better than $p1.
-Barry
signature.asc
Description: This is a digitall
On Wed, 2005-09-07 at 15:07, Bob Ippolito wrote:
> I was also able to easily automate the process of extracting strings
> to create that spreadsheet. I wrote a simple script that parsed the
> Python modules and looked for function calls of "_" whose only
> argument was a constant string. W
On Thu, 2005-09-08 at 07:48, Antoine Pitrou wrote:
> As I said Python needs an operator or function that does string
> formatting using a simple template, *without* doing output at the same
> time. The current syntax is the '%' operator, it could change, but it
> shouldn't be removed in favor of a
Raymond requested, and Guido concurred, that the python-checkins mailing
list Reply-To header munging be turned off. I've now done this.
Previously, follow-ups to checkins would be addressed to python-dev.
Now, follow-ups will stay on the python-checkins list and will not
appear here, unless the
On Mon, 2005-09-19 at 17:52, Scott David Daniels wrote:
> Michael Hudson wrote:
>
> > How does a copying gc differ much from a non-copying non-refcounted gc
> > here?
>
> One important issue for C coded modules is that addresses may change
> when a GC is invoked, so no remembering addresses in yo
On Mon, 2005-09-19 at 20:03, Guido van Rossum wrote:
> While you're at it, maybe we should switch to && and || as well?
> That's another thing I always mistype when switching between
> languages...
Please no! 'and' and 'or' is so readably beautiful.
> Also, this proposal needs to be considered
On Tue, 2005-09-20 at 17:40, Guido van Rossum wrote:
> Ouch. You're bringing up another valid issue: whether to support
> "elif". I think if we go with (if ... then ... else ...) or (if ...:
> ... else: ...) we'll have to support elif as well:
I'm not so sure. Once you start writing such a compl
On Tue, 2005-09-20 at 18:21, Thomas Lotze wrote:
> Nothing prevents you from spreading the code over multiple lines, like so:
>
> x = (if a then b
> elif c then d
> else e)
>
> or even
>
> x = (if a then
> b
> elif c then
> d
> else
> e
> )
>
> e
On Wed, 2005-09-28 at 10:16, Jim Fulton wrote:
> When we ask for the eggs attribute the first time, we call the
> descriptor, which calls the eggs function. The function sets the eggs
> attribute, overriding the descriptor. The next time the eggs attribute
> is accessed, the saved value will be u
On Wed, 2005-09-28 at 19:14, Phillip J. Eby wrote:
> Because it only works in classic classes due to a bug in descriptor handling:
Blah. ;)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-D
On Thu, 2005-09-29 at 21:21, Guido van Rossum wrote:
> Flames, pleas to reconsider, etc., to /dev/null.
>
> Congratulations gracefully accepted.
>
> It's still my language! :-)
Congratulations! May this be as successful a syntax addition as
decorators and print>> (of which I'm a fan too! :).
On Fri, 2005-10-07 at 14:42, Shane Hathaway wrote:
> What's insanely difficult is really locking, and locking is driven by
> concurrency in general, not just threads. It's hard to reason about
> locks.
I think that's a very interesting observation! I have not built a
tremendous number of co
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 t
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, with
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
q
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 an
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 probl
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 - dir/containi
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 cross-comp
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 Mon, 2005-11-21 at 16:09 +0100, Armin Rigo wrote:
> It might be me, but I find it a bit odd that you didn't do anything with
> this fix.
Hi Armin. Actually it was SF #900092 that I was referring to. We fixed
this bug and those patches were applied to CVS (pre-svn conversion) for
both 2.4.2
Unless there are any objections, I'd like to create a space in the
sandbox for the standalone email package miscellany. This currently
lives in the mimelib project's hidden CVS on SF, but that seems pretty
silly.
Basically I'm just going to add the test script, setup.py, generated
html docs and
On Fri, 2005-12-09 at 15:38 -0600, Ian Bicking wrote:
> I was reading through PEP 8, and I think there's a few things that could
> be clarified or updated:
BTW, I'm willing to make updates to PEP 8, if we agree on what to
change.
> Exception Names
>
>If a module defines a single ex
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
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
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
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 u
On Mon, 2005-12-12 at 14:22 -0500, Jeremy Hylton wrote:
> The C files are checked into subversion. Perhaps there is some
> problem with the timestamps that causes the Makefile to try to rebuild
> them anyway? I have a modern Python and I've been doing a fair amount
> of development on these files
On Tue, 2005-12-13 at 23:52 +0900, Stephen J. Turnbull wrote:
> I'd be happy to make some time to describe the XEmacs scheme and
> experience if somebody wants. However, XEmacs faces language and code
> organization constraints that Python does not, and Fredrik's
> suggestion looks like a substan
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 alway
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
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
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
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
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 pre
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 digitall
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 digit
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 ;) pro
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 poss
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 ob
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 s
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
> > &
On Thu, 2005-12-15 at 11:22 +0100, [EMAIL PROTECTED]
wrote:
> I hope new stuff will follow only one naming style. And now we should
> (or one person :-) should) decide which one.
I guess my point boils down to, we already did decide 4 years ago.
Let's stick with what we've got.
-Barry
signatu
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, b
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 t
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,
in
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
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 alt
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&
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
On Wed, 2005-12-21 at 22:40 +0100, Fredrik Lundh wrote:
> > Sorry, but HTML and (even more so) XML are not human-writable. :) Yeah,
> > we can all do the simple stuff, but I absolutely hate authoring in HTML,
> > and it would be a nightmare if the documentation production system
> > didn't handle
On Thu, 2005-12-29 at 22:29 -0600, Ka-Ping Yee wrote:
> In a fair number of cases, Python doesn't follow its own recommended
> naming conventions. Changing these things would break backward
> compatibility, so they are out of the question for Python 2.*, but
> it would be nice to keep these in min
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" t
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 k
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
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
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 Tim
On Mon, 2006-01-09 at 14:08 -0300, Facundo Batista wrote:
> We can rewrite ConfigParser to store everything and write it back in
> the exact order it took it, with new values at the end of each section
> (or where the user inserted it), but it'll took a big rewrite of the
> module: right now it's
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
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 "5".en
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 i
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(). Un
On Fri, 2006-01-20 at 21:43 +0100, Thomas Wouters wrote:
> I don't believe this belongs in 2.4, since it can, actually, break code.
> Code that depends on the current situation, _TestCase__attributename.
> Fragile code, to be sure, but still. If there were a compelling reason to
> backport, I gues
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 readline
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
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
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
> does
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 sto
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
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 be
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,
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
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 messa
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 o
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
wee
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 response
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
> involvemen
2601 - 2700 of 2704 matches
Mail list logo
