On Mon, 2005-08-22 at 12:16, "Martin v. Löwis" wrote:
> Barry Warsaw wrote:
> > I think technically, the answer to that is "yes", you will automatically
> > get access to the source repo.
>
> At the moment, the answer actually is "no". For
On Tue, 2005-08-23 at 11:51, Fredrik Lundh wrote:
> Gareth McCaughan wrote:
>
> > It's valid C99, meaning "this is an unsigned long long".
>
> since when does Python require C99 compilers?
Why, since Python 3.0 of course!
-Barry
signature.asc
Descri
-errors like SystemExit or KeyboardInterrupt.
I can't remember ever writing a bare except with a suite that didn't
contain (end in?) a bare raise. Maybe we can allow bare except, but
constrain things so that the only way out of its suite is via a bare
raise.
-Barry
si
whether getting rid of this common idiom is
trading one common problem for another.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
seException" will work like a bare except clause does now.
Sorry Raymond, but my first reaction is "ick" :). That seems to be a
big change in the semantics of exception matching. I think I'd rather
keep bare except than add that!
-Barry
signature.asc
Description: Th
get a chance to do so for several
days.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
d be
> >len(sep), to preserve the current proposal.
+1 on the concept -- very nice Raymond.
> Unrelated comment: maybe 'cut()' and rcut() would be nice short names.
FWIW, +1 on .cut(), +0 on .partition()
-Barry
signature.asc
that the docs describe the compiled method
names in terms of the uncompiled functions. I always find myself
looking up the regexp object's API only to be shuffled off to the
module's API and then having to do the argument remapping myself.
-Barry
were in charge, I'd rename it to something more informative.
Maybe like getorset() .
Oh, and yeah, I don't care if we change .setdefault() to require its
second argument -- I've never used it without one. But don't remove the
method, it's quite handy.
-Ba
e ever"...
/And/ the rule was self-admittedly broken by Guido not a few posts after
that one. ;)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
ft
> like "from sys import stdout".
I agree. You can't get much simpler to explain or use than the current
print statement.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev
to beat the useability of print with a
write() function, even if builtin.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
han debugging. And while I do
occasionally use it, I wouldn't be too heartbroken if the trailing comma
form were lost. I /would/ mourn the loss of print>> though -- not
necessarily the syntax, which was clearly a compromise, but the
functionality. If we could have spelled it &qu
ing writeln() or writefmt() or whatever -- those seem like useful
additions I'm sure I'd use. But I don't think that therefore (or under
the principles of TOOWTDI or cleanliness) demands the removal of print.
-Barry
signature.asc
Description: This is
ot;)
Or maybe
print >> sys.stderr, "\
This is a long sentence that I didn't have to cut in two."
A bit yucky, but easily extended to TQS when your message gets longer
and longer.
-Barry
signature.asc
Description: This is a digitally signed message part
___
elieve the person who said the trailing comma case mixed up anybody,
> not for more than 10 seconds anyway.
>
> OK, now that I've offended everyone, I'll go back into retirement. But I
> *am* laughing at you.
Thank you Paul! Don't stay retired for long. :)
-Bar
yword
> parameters to suppress the trailing newline or the space between
> items); would anyone support a proposal to make it a statement
> instead?
Probably not, but such an alternative universe is hard to imagine, so
I'm not sure it would have dawned on anyone t
ment to decide whether it's a format string or not. Ick!
So I think it's best to have two builtins:
print(*args, **kws)
printf(fmt, *args, **kws)
I would also /require/ that any behavior changing keyword arguments
/not/ be magically inferred from the positional arguments. So you
27;nl' keyword
arguments, and not having the ability to print Separator instances
directly, but OTOH maybe those aren't big deals.
Anyway, this is close to what (I think) I'd like to see in the proposed
built-ins. I'm out of time for now, so I'll check back later for all
On Sat, 2005-09-03 at 12:51, James Y Knight wrote:
> On Sep 3, 2005, at 11:32 AM, Barry Warsaw wrote:
>
> > So I think it's best to have two builtins:
> >
> > print(*args, **kws)
> > printf(fmt, *args, **kws)
>
> It seems pretty bogus to me
On Sat, 2005-09-03 at 14:42, Paul Moore wrote:
> I have to agree. While I accept that Barry has genuine use cases for
> the printf form, I don't quite see why %-formatting isn't enough. Is
> the print-plus-% form so much less readable and/or maintainable?
IMO, yes. I can&
ot;print" "" 'python-abbrev-print)
LOL! That's a great solution for the 5 of us dinosaurs still using the
One True Editor. :)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing li
e
> 'format' builtin more generally useful, as it can be used for cases other than
> direct output to a stream.
The downside being that you have to type more to get the behavior you
want. It does have the advantage of solving the namespace problem.
-Barry
signature.asc
Desc
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 p
hink Guido and others have explained the problems with %. Also,
we already have precedence in format+print in the logging package. I
actually think the logging provides a nice, fairly to use interface that
print-ng can be modeled on.
-Barry
signature.asc
Description: This is a digitally signed mess
e argument values (if any) without any formatting --
> when logging, that's a much better thing to do than dying with an
> exception. As I said, not sure if printf() should have the same
> behavior; it's wort a try though.
Cool idea, definitely worth a try.
-Barry
signature.
.
Actually, this was part of the motivation behind PEP 292 and Template
strings, because what you really want is named parameters, not
positional parameters:
'The file $filename in directory $dir is read only'
There are a few techniques for get
hat IME, %(var)s is an error-prone construct for translators.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ate the other namespace wart. Is
this really too horrible:
print('$user forgot to frobnicate the $file!\n',
user=username, file=file.name, __to__=sys.stderr)
> BTW we could use "from __future__ import printing" to disable the
> recognition of 'print' as a k
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
at we can make it easy for monolinguists to
use printng without caring or even knowing about i18n, but also make it
relatively painless to integrate i18n into an application or library.
However I haven't had time to really explore that idea.
-Barry
signature.asc
Description: This is a di
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
signatu
printf() should be easy to recognize, although we
might have to make a slight modification since IIRC, pygettext will only
extract strings from keyword functions with exactly one argument. That
should be easy to fix.
-Barry
signature.asc
Description: This is a di
fter all, print's entire purpose is convenience.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
nless the poster explicitly redirects it.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
no remembering addresses in your module; you
> must recalculate before each use.
And then you're left with "fun" like JNI's pining and such. That won't
suck at all! :)
-Barry
signature.asc
Description: This is a digitally signed message part
___
.
> Also, this proposal needs to be considered together with the addition
> of a proper conditional operator, like x?y:z.
Definitely.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-D
re. Once you start writing such a complicated thing, I
think readability will favor just breaking the code out into traditional
if-blocks. I'd be happy enough with just a binary condition.
-Barry
signature.asc
Description: This is a digitally signed message part
___
s compared to its if-statement companion.
I guess that's my point. To me, your latter is actually worse than
if a:
x = b
elif c:
x = d
else:
x = e
I think the conditional stuff gets the most bang for the buck in
situations like:
d[foo] = if a then b else c
-Barry
s
;d be happy to add this for 2.5.
I /must/ be missing something. Why not just use property as a
decorator?
class C:
@property
def eggs(self):
print 'in eggs'
self.eggs = 7
return self.eggs
>>> c = C()
>>> c.eggs
in eggs
7
>>> c
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
Pyt
t; (of which I'm a fan too! :).
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
endent-consumers architecture that was
outlined in a previous message. In that case, if you can narrow your
touch points to the Queue module for example, then yeah, threading is
easy. A gaggle of independent workers isn't that hard to get right in
Python.
-Barry
signature.asc
Description:
> ever there was a makethreadsafe decorator, it should go in the thread
> module, etc. I mean, come on, its like making a module just to store a
> bunch of unrelated types just to lump them together because they're
> types. Who wants that?
Like itertools?
+1 for a decorators module.
-Barry
;, 'setFoo', None, 'the foo property')
>
> def getFoo(self):
> return self._foo
>
> def setFoo(self, foo):
> self._foo = foo
>
> What do you think?
Ick, for all the reasons that strings are less appealing than names.
IMO, ther
super(B, self)._set_x(x)
def _get_x(self):
print 'B._get_x()'
return super(B, self)._get_x()
a = A()
b = B()
a.x = 7
b.x = 9
print a.x
print b.x
Basically A.get_x() and A.set_x() are just wrappers to make the property
machinery work the way you want.
-Barry
signat
do the wrapping in property(). I put that in
quotes because you'd have the problem of knowing when to wrap and when
not to, but there would be ways to solve that. But I won't belabor the
point any longer, except to ask what happens when you typo one of those
strings? What kind
e to see
if there is any interest.
http://www.python.org/peps/pep-0351.html
Cheers,
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
tic.
I also would love it to be hooked into vc-mode too, for modeline updates
and commits of single files. I can understand why those things aren't
there yet though. All in all psvn.el works very well, although it's not
(for me) a complete replacement for the command line.
-Barr
you'll see something like:
Author: person
Date: when
New Revision: r12345
Log:
Log message comes next. Definitely best to show up before the diff.
diff comes next...
FWIW, this format has worked well for us.
-Barry
signature.asc
Description: This is
For some of the modules, we want the
auto-detection code to find versions of dependent libraries in locations
other than the "standard" system locations. I don't think there's a
good way to convince the various setup.py scripts to look elsewhere for
things, short of modifying
'm not sure I
like the idea of three profilers in the stdlib, I think in this case
(unless they're incompatible) it would make sense to keep hotshot
around, at least until any new profiler proves it's better over a couple
of releases.
-Barry
signature.asc
Descrip
ked up Python.
E.g. we were running 2.4.1 with this (and a few other patches) until
2.4.2 came out, but now we're pretty much using pristine Python 2.4.2.
So I still think hotshot can stay in the stdlib for a few releases,
unless it's totally incompatible with lsprof, and then it'
rated
html docs and a few additional unit tests, along with svn:external refs
to pull in Lib/email from the appropriate Python svn tree. This way,
I'll be able to create standalone email packages from the sandbox (which
I need to do because I plan on fixing a few outstanding email bugs).
-Ba
d in "Error"?
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".
Also, I have some additional guidelines adapted
t;Here is a triple quoted, multiline string
Some people write the continuation lines starting
in this column, but I don't like that.
"""
-Barry
signature.asc
Description: This is a digitally signed message part
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
same name.
Note 1: Note that only the simple class name is used in the mangled
name, so if a subclass chooses both the same class name and attribute
name, you can still get name collisions.
Note 2: Name mangling can make certain uses, such
tted imports should be grouped roughly alphabetically.
>
> This seems too complex to me for PEP 8.
Really? ISTR adopting this convention from Guido, but I'm not 100% sure
about that. After having used it for several years now, I do really
like this sty
it should go in that direction.
I'm not exactly sure if this is what you're getting at, but one thing
that bothers me is using data attributes to trigger actions. Maybe this
gets into the "no side-effects" rule for data attributes, but attributes
that cause an object to per
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.
> P
elopment on these files; as a result, I haven't noticed a
> problem.
I tried this early today: svn up; make distclean; configure; make
Unfortunately, that requires Python to already exist, so there's
definitely a boostrapping issue in the build process.
-Barry
signature.asc
Descripti
uggestion looks like a substantial improvement over the system XEmacs
> has in place.
>
> Even with its defects, it's been a great success for us.
I'd love to read about the way XEmacs is doing this.
-Barry
signature.asc
Description
ght the answer to that was always "no".
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
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
Descri
w-style classes.
> >
> > Note 2: Try to keep the functional behavior side-effect free,
> > although
> > side-effects such as caching are generally fine.
>
> Personally, I'd actively discourage use of trivial accessors. Simple
> attribute acce
e. I think they have a notion of "virtual" packages,
such as "mta" or "X" which various specific packages such as sendmail,
postfix, X11 or xorg can fulfill.
-Barry
signature.asc
Description: This is a digitally signed message part
__
on-native English speakers (particularly those not coming from a
> European alphabet) that it was far easier to read with underscore
> separation rather than capWords.
Correct, which is one reason I feel strongly that we should keep the
current recommenda
ely.
> > The use of lowercase with underscores is the default so
> > the python std lib should use it in all modules.
>
> Too late. I don't think the diversity is all that distracting. I'd be
> much more concerned about spelling MethodNames (as unfortunately the
>
what) more prescriptive.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/
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 th
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
Descri
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
parates the doc string paragraphs from the code
> better.)
I'm just trying to suss out whether the reason is linked to the old
python-mode bug or whether there's a stylistic motivation here. If it's
the former, I think we should remove the recommendation. If it's the
latte
, I think the
underline_words recommendation should stand.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
PEP 263 tests is kind of obvious.
Agreed.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.or
won't write that PEP. If someone does, we can
link to it from PEP 8.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
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'
intended for the stdlib, should follow the PEP's guidelines.
Which is why I think we need one strong recommendation. Over time, as
modules are naturally updated or supplanted, we'll get more consistency
in the stdlib across packages.
-Barry
signature.asc
Descriptio
y interest in this patch? I'm happy to commit it if there
are no objections.
-Barry
Python 2.5a0 (#41708, Dec 15 2005, 23:59:14)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2
Type "help", "copyright", "credits" or "license" for more
talk about a specific svn
revision easily from a built Python, even if that's installed and moved
to a location apart from the svn working directory.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing l
t Python developers will just svn up at the top of the source
tree, then rebuild, rather than svn up some buried sub-tree, cd back to
the top and rebuild from there. At least, that's how I generally work
with the Python tree.
-Barry
signature.asc
Description: This is a
int.
Other than that, it sounds like this is a generally acceptable change to
make to the build process, so I'll make the above modifications and
commit it.
Thanks everyone,
-Barry
signature.asc
Description: This is a digitally signed message part
__
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
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 digitall
n about the current LaTeX documentation?
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
and "someone" will
mark it up.
Heck, I wouldn't mind an xml2latex converter so those that like a
different kind of pain (writing xml vs. installing latex) can still
contribute documentation and we can convert it to back to latex.
-Barry
signature.asc
Description: This is a d
e use of the shift key. Now, I
personally swap capslock and control so it would be a PITA for
me, but doable. But I know a lot of people who disable capslock
altogether so they'd be performing all kinds of pinkie stretching
gymnastics all the time.
-Barry
signature.asc
Description: Thi
y a distclean, and modify the
build process to generate Python-ast.* from those template files.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
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
correctly.
>
> Is this a known issue, or is it irrelevant?
Dunno, but I'm always having problems w/ Solaris tar, so I just use GNU
tar on Solaris. ;)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-D
is going to be modifying this file anyway. PEP 101 should be
updated so that updating patchlevel.h be the last commit before an svn
export is done (but that PEP needs an overhaul anyway to change the cvs
references into svn commands).
Thoughts?
-Bar
e in that tag as the very last
thing we do before we create the tarball. Or is that too evil?
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
.1. But email 3.0 need only be compatible with
Python 2.3. Given that we now have everything in Subversion, I think it
makes it much easier to maintain multiple versions of separately
distributed packages, modulo the time it takes to do so.
-Barry
signature.asc
Description: This is a d
razy things like keep your
configuration files in a revision control system. That's something that
I do as much as possible. In general it works great for some thing, and
pretty poorly for others, but when it works it makes keeping systems in
sync or backed up much easier.
-Barry
signatu
cklevel=2)
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?
-Barry
signature.asc
Description: This is a digitally signed message part
__
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
2701 - 2800 of 2826 matches
Mail list logo
