t;
> I wouldn't mind seeing arbitrary base encoding of integers included somewhere,
> but as a method of str -- let alone the constructor! -- it feels quite wrong.
Hear, hear. I was similarly perplexed when I first read that!
-Barry
signature.asc
Description: This is a digitall
he obvious choice is probably "b".
>
> For example:
>
> >>> '%08b' % (12)
> '1100'
> >>> '%b' % (12)
> '1100'
+1
-Barry
signature.asc
Description: This is a digitally signed message part
__
t.
(There was something else that bugged me about the OS X 10.4 Python
from-source build but now I can't remember.)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http
l literals is handy for things like os.chmod(). Unix
weenies shouldn't be totally forgotten in P3K. I'm also for keeping
hex() and oct() although if you want to move them out of builtins,
that's fine. +0b1 for binary literals and %b.
-Barry
signatu
> backport, I guess it could be hacked to work right-ish, but subclassing
> TestCase in this way, while convenient, isn't important enough to warrant
> this (IMHO).
Exactly right.
-Barry
signature.asc
Description: This is a digitally signed message part
__
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. If that /happens/ to cause a
different version of readline to be used as a side-effect, then oops!
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
efficient than having to create a bunch of intermediate
objects.
All in all, I'd have to say I'm -0 on __div__ for path concatenation.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-
. It's a
trade-off that should be made for practical purposes. I've definitely
come to prefer spellings like is_absolute over isabsolute, and in
general dislike squish words.
-Barry
signature.asc
Description: This is a digitally signed message part
___
as much, and
> doesn't
> raise precedence and readability questions.
Or the need to employ ugliness like backslashes when you have to split
the join across multiple lines.
-Barry
signature.asc
Description: This is a digitally signed message part
___
me. It's actually jarring enough that I
have to stop and think about what it means because it /looks/ like
there's math going on.
OTOH, something like:
image = Path('', 'images', name) + ext
or even better
image = Path.join('', 'images', name) +
shed out in more
detail. If it's proved to be an impossible (or merely an extremely
infeasible) task, then I think we can discuss the shortcut of deriving
from strings. It just seems gross so I'd like to be sure there's no
better way.
-Barry
signature.asc
Description: This is
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
d suggest we do nothing unless the FSF asks us to.
-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
0xff, 0o664, and 0b1001001 seems like
the right direction, although 'o' for octal literal looks kind of funky.
Maybe 'c' for oCtal? (remember it's 'x' for heXadecimal).
-Barry
signature.asc
Description: This is a digitally signed message part
___
ary for bit flags and other bit twiddling, and oct
for OS/file system interfaces. In none of those cases do you actually
need or want signed values. IME.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mai
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
unit tests of some random Python implemented mailing
list manager. Just fer instance. But still...
> But I can't speak for how often this need comes up among users.
Yeah, there is that. ;)
-Barry
signature.asc
Description: This is a digitally
m doing a lot more dev on the Mac these days, I definitely
agree that this is what makes Gentoo so cool for Linux, and I can't wait
for Gentoo-on-OSX to switch to doing things the Right Way (can you say
bye-bye DarwinPorts?).
-Barry
signature.asc
Description: This is a digitally signed me
;d like to keep discussion on the email-sig, so please join us there if
you care about this one way or the other.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
riety.
I've long advocated for keeping <> as I find it much more visually
distinctive when reading code.
-Barry
___
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
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
on
> to remove it is another question.
Visually, "==" looks very symmetrical and stands out nicely, while "!="
is asymmetric and jarring. "<>" has a visual symmetry that is a nice
counterpart to "==". For me, t
;t shed a tear if it
were rejected.
One other un-PEP'd thing. I'd 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?
-Barry
_
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
e thread.
>
> Could you please do that? I'd like to understand all of your
> objections. Thanks!
Better yet, add them to the PEP.
-Barry
___
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
2801 - 2826 of 2826 matches
Mail list logo
