owstoppers and several green buildbots, so I'm going to make the
releases tonight. Please, NO CHECKINS until I say so, or ping me on
#python-dev.
As for bsddb, we'll make a determination after beta3. If it's terminally
busted for Python 3.0, so be it.
Thanks everyone for working so h
d other iterators could chose to raise TypeError
if they have an unknown size.
There are probably all sorts of reasons why this won't work, but it
seems like it would be useful.
-Barry
signature.asc
Description: This is a digitally signed message part
___
a tie-breaker then backward compatibility may tip the
scales against a particular change.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/li
terator can help in those
situations though.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.py
eople could set their
> editors to display indentation however they wanted, and
> there would be no need to argue about how many spaces
> should be dancing at the head of a code line.
4 space tabs are evil, as are all-tab styles. Everyone knows that a tab
is 8 spaces. :)
-Barry
signature.
On Fri, 2006-03-24 at 07:26 -0800, Guido van Rossum wrote:
> On 3/24/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > On Thu, 2006-03-23 at 17:06 -0800, Guido van Rossum wrote:
> >
> > > The pattern with the 'empty' flag is only needed when due to API
> &g
character-wide source file.
>
>
> Don't forget those of us who are now pushing for 120 character wide
> source files!
Please gawd no!
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 ma
On Sun, 2006-04-02 at 22:27 +0200, Georg Brandl wrote:
> BTW, has anyone seen string.Template being used somewhere?
I use it, which shouldn't be a big suprise (though not in much public
code). You'll probably see it get used quite a bit in a future Mailman
release.
-Barry
ltin substitution
> engine, at least.
PEP 292.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mai
prefix, but I agree that it would be nicer if
there were more direct support for $-strings. OTOH, I don't see a good
way to marry the rich coercion of %-substitution with the simplicity of
$-substition. I wouldn't want to lose that simplicity to gain that
richness in $-
and try to explain
> it. For instance, the documentation for Decimal is pretty clear as to when
> Decimal is to be used and how it is different from float.
There's a link to PEP 292 in the documentation, but if you feel that's
not enough, feel free to submit a patch.
-Barry
s
7;m willing to believe that my uses are fairly narrow and that such a
builtin could be useful for other applications, but I don't see too much
of a benefit for the code I've written.
-Barry
signature.asc
Description: This is a digitally signed message part
_
cals out of the calling
function, and does the substitutions from there. So, if your
applications isn't i18n, I could see the use for a format() global, but
while I'd probably want the behavior I just described, you might not, so
I'm not sure we could write a format() builtin that w
nt _("%{utils.websafe(form.get('user'))}s is not a member of the
> %{mlist.get_name()}s mailing list")
I wouldn't use it because it would be way too easy for translators to
make catastrophic mistakes.
-Barry
signature.asc
Description: This is a digitally signed
s a
> continuum of use cases.
Except with some language's plural forms (e.g. Polish IIUC) simple
expressions like that won't cut it. OTOH, gettext has facilities for
supporting all those bizarre plural forms so I don't think we have to
reinvent them in Python (though we may n
ot; % (path,
> path). But the first form is really better in several ways.
>
> If .substitute() (or .sub()?) was available to do $-based substitution
> alongside .format() for %-based substitution, that would both have a
> nice symmetry and make it mor
e strings really really simple. I think
most translators can grok simple $-substitutions because they've seen
those in many other languages.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 mailing l
292 tried to make inserting
strings into other strings really simple to grok, and I think it does
that, while still providing a useful level of flexibility for advanced
users. I really would hate to mingle that simple functionality with all
the complexity of number formatting and the like.
-Barry
t...
> Though I also agree that $"answer: $answer" introduces a confusing
> number of $'s.
...I agree too! :)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 mailing list
Python-3000@
nst changing any human readable text. When
I retire , that's a project I would like to tackle (and have some
ideas along those lines).
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 mailing list
Python
utside the string. It seems to me that
> something like
>
>"User {user} has printed {n} pages"
>
> sets off the parameters from the rest of the
> string more readably than
>
>"User $user has printed $n pages"
Here i disagree. $-strin
n for any
getters and setters that take no arguments, both for pure-Python types
and C-implemented types. While we were at it, we changed everything
that returns a newly formed concrete sequence to returning an iterator
(which broke code that was doing random access into the sequence, but
that's
this, but it appears not. But that's an aside.
>
I may be misunderstanding, but the contents of ${...} is pretty
flexible because you control the regular expression that matches the
substitution. Heck, you can even use something other than $
if your substitution variable
is followed by "non-identifier" characters, just use $what, otherwise
use ${what}.
I haven't tried, but string.Template might even support dropping the
delimiter altogether, so that you could use just {what}. Give it a
shot and let us know! :)
it's
very rarely used. So I wouldn't be in favor of changing it. Of
course, beauty is in the eye of the beholder and all that...
-Barry
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-30
hink Ruby stole the idea and syntax from Lisp. It's an
interesting idea, but I'd like to understand exactly what you mean by "a
Python symbol". Can you give more detail about your idea, perhaps as a
pseudo-PEP?
-Barry
signature.asc
Description:
ly in expressions:
>
> if python.has_punctuation?() and someone.uses_it_often?:
>print "Please don't do it!"
>
> PS. .uses_it_often? is an attribute, not a function here...
That's what _p suffix is for. :)
-Barry
signa
uot;s from their experience with other
> languages, but the self in the signature (and the miscount of arguments
> in TypeError exceptions)
I'd rather fix this nit than remove self.
-Barry
signature.asc
Description: This is a digitally signed message part
___
ely, and the container-like nature of bytes is
> clearer. So I don't propose this effect bytes in any way.
That seems right. bytes probably won't suffer from the Python String
Photonic Effect (that they're both waves and particles, er, I mean
sequences and scalars).
-Barry
s
change for practical reasons, but I
think that treating strings as atoms by default makes sense.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 mailing list
[email protected]
http://mail.python.org/
at strings atomically much more often then
they want to treat them as a sequence of characters.
nuff-said-moving-on-ly y'rs,
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 mailing list
Python-3000@pyt
On Wed, 2006-04-19 at 20:17 +1000, Nick Coghlan wrote:
> Unfortunately, the thread fizzled without generating any additional interest.
> I don't recall the topic really coming up since then.
Maybe because the proposal got too complex while trying to be so
general?
-Barry
si
e
> particularly strong opinions either.
For the use case that string.Template was originally designed for, I
definitely agree. OTOH, as long as we don't change string.Template, it
can still be used for simple string substitutions (hence the title of
PEP 292) where all the extra f
On Fri, 2006-04-21 at 14:39 -0700, Raymond Hettinger wrote:
> >- I like having an operator for string formatting. I'm -0 on dropping it for
> >a .format() method.
> IMO, a named method solves all of these
> issues.
+1 for a method to replace the operator.
-Barry
si
the literal alternatives (at least for the former).
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail
former ;)
>
> The former. I thought it was already decided?
Yes, it was.
> Of course, only for
> *new* code so far, to ease merges.
Definitely, although there should be a flag day at some point where we
reformat the old code, which I definitely think we should do, as painful
as it migh
On Mon, 2006-04-24 at 11:18 -0700, Guido van Rossum wrote:
> The former. I thought it was already decided? Of course, only for
> *new* code so far, to ease merges.
Here's a tiny bit of Emacs Lisp that should support the py3k style.
Only moderately tested in XEmacs 21.5.
-Barry
(de
unds good to me. I guess when someone is about to do significant work
on a C file, we should ask on this list about that possibility, and if
it's low, then we can reformat the file at that time.
-Barry
signature.asc
Description: This is a digitally signed message part
___
(x) for x in seq]
just another way to spell
list(genexp) where genexp == f(x) for x in eq?
So, if there are no list comps any more, but list literal notation could
take a genexp, doesn't that give us today's syntactic convenience with
tomorrow's consistence world view?
-Barry
sig
:
>
>{ name="Frodo", race="Hobbit" }
>
> instead of:
>
>{ 'name':'Frodo', 'race':'Hobbit' }
>
> (Only 4 characters longer, but *much* harder to type. Try typing it if you
> don't
> believe me.)
On Wed, 2006-04-26 at 12:07 -0400, Jim Jewett wrote:
> Alternatively, define a classmethod for the literal form. For me,
> even the much longer
>
> s = set.literal(1, 2, 3)
Or how about just set.new(1, 2, 3) ?
not-sure-it's-worth-it-ly y'rs,
-Barry
signature.asc
in() builtin would be fine if it
took the string arg first, so that
''.join(seq) == join('', seq)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 mailing list
[email protected]
http:
e out?
Now, in a case like the following, you /would/ want a tuple, but only to
preserve order:
x = (1, 2, 3)
foo(*x)
are tuple literals used enough this way, and what if you were forced to
use a list literal instead?
x = [1, 2, 3]
foo(*x)
So, again, what if (...) created a set/fr
e how if Guido wants both dict and set comprehensions, he
> couldn't have them.)
Can I unwithdraw PEP 274 now?
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 mailing list
[email protected]
ht
On Thu, 2006-04-27 at 16:44 -0400, Barry Warsaw wrote:
> for x in (1, 2, 3, 5, 7, 11)
Uh, ignore that. Order matters.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 mailing list
Python-3000@python.
We actually have two ways to create
literal tuples, right?
x = 1, 2, 3
x = (1, 2, 3)
So let's keep the first and hijack the second to be set constructor
notation. As for your other questions, I dunno, it was a dumb idea. :)
-Barry
signature.asc
Description:
them occasionally. There are
others, but those are probably the majority of them. I'm not sure what
that tells us, except that I don't think there's an obvious default.
You could probably argue for the emptystring just as well as for the
space
als. We can always add {/} later if demand exceeds distaste.
+1
> Also, FWIW, I think the current dict constructor is fine as-is. No
> doubt that its API is fully-loaded, but it is very useful and not hard
> to learn. Practicality wins here.
+1
-Barry
signature.asc
Description
stered and we could permanently disable it. If they didn't match,
or it was some other kind of error, we could potentially treat that as a
temporary problem and just skip the callback but not permanently disable
it.
-Barry
signature.asc
Description: This is a digitally signed message part
___
On Mon, 2006-05-08 at 20:36 +0200, Marcin 'Qrczak' Kowalczyk wrote:
> Barry Warsaw <[EMAIL PROTECTED]> writes:
>
> > Obviously if someone registers a callback that isn't callable,
> > we don't want to waste time on every iteration trying to call it,
On Mon, 2006-05-08 at 09:47 -0600, Steven Bethard wrote:
> On 5/8/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > Perhaps then, if we get rid of callable()/PyCallable_Check() it would be
> > useful to add a NotCallableError (as a subclass of TypeError?) that
> > would g
> usefulness of being able to distinguish between those different
> failure modes at run time. Others do. I doubt that one side is able to
> convince the other side. So let's agree to disagree.
What about including the object you tried to call as an attribute on the
TypeError?
-Barry
sig
me all that much (okay, okay, so we're trading one for
the other :). I strongly prefer 'case in' for multiple cases than
any of the other alternatives.
I'd also be mildly in favor of default fall-thru a la C, but with
'case in' I don't care too much
quivalent
> to "raise ValueError()") or that it should be disallowed.
I say keep it. I don't see much value in requiring empty
parentheses, except maybe to keep my left pinkie limber.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBROiJtX
I agree with Tim -- if we have to get rid of one of them, let's get
rid of index/rindex and keep find/rfind. Catching the exception is
much less convenient than testing for -1.
-Barry
___
Python-3000 mailing list
[email protected]
ut not all. Maybe
str.partition completes the picture, though I don't have enough
experience with them to know.
Anyway, enough blathering. Those are my thoughts. For this
specific case, maybe we really don't need any of ?find() and ?index(),
but if the choice comes down to one or the othe
s with non-integer indices. We'd definitely want
to preserve the ability to do that.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRPOiDnEjvBPtnXfVAQJAWwQAnna3MD7qKDY0SFYyTmN/Dnoy3nBrsP/l
kemAn8Rqdj/3EL/iJuesI8N81BtH6CUp3BR0XzCUpKnsTCcyZxjo9M9d96aF18Jm
A8K/Q
hatever makes the most sense for the most general
audience. I'm eager to never have to worry about 8-bit strings vs.
unicode strings, how they mix and match, and all the nasty corners
when they interact. I'd hate to trade that for the worry about
whether I have a string or a st
ler() could then splice in whatever values
it wants. Yeah 'None' for the missing ones can be ambiguous but oh
well.
You raise a ValueError if filler is a sequence of size that doesn't
match the number of zip arguments or if filler() doesn't return an
appropriately sized s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 31, 2006, at 11:38 AM, Jim Jewett wrote:
> On 8/30/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
>> What about a keyword argument called 'filler' which can be an n-sized
>> sequence or a callable.
>
>
e saying "go here for more advanced usage". There's a ton of
stuff in Python that total beginners just don't need to know right away.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRPcqQ3EjvBPtnXfVAQJxSAP/Yk2Dqh88iHThSKoqHHr9rURGbO2UWPvt
R4
the hell out of several
Gentooers until we tracked down all the resources and figured out the
(suboptimal) fix.
-Barry
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
uldn't be rewritten to use
absolute seek, but it's also not the most natural interface. I'd opt
for keeping those interfaces for binary files since there are use-
cases where they are useful.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRQ
unpredictability of gc vs. refcounting. For
some class of Python applications it's important that when an object
is dereferenced it really goes away right then. I /like/ reference
counting!
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRQ7aCHEjvBPtnXf
gain. :) Would a garbage collection interface make this easier
(because you could ignore all that) or would you be trading that off
for things like gcpro in Emacs, which can be just as harmful if you
screw then up?
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Da
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 18, 2006, at 4:33 PM, Jim Jewett wrote:
> On 9/18/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
>> ... I agree with Raymond that it can be quite difficult to get
>> C code to be refcount-correct, ...
>
> How
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 19, 2006, at 10:42 AM, Marcin 'Qrczak' Kowalczyk wrote:
> Barry Warsaw <[EMAIL PROTECTED]> writes:
>
>> What worries me is the unpredictability of gc vs. refcounting. For
>> some class of Python applications
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 19, 2006, at 11:29 AM, Marcin 'Qrczak' Kowalczyk wrote:
> Barry Warsaw <[EMAIL PROTECTED]> writes:
>
>> I don't see how that helps. I can remove all references to the
>> object but I still have to
a lot of different efficiency parameters to consider, and
of course different applications will care more about some than
others. A u/i-based tool doesn't want noticeable pauses. A long
running daemon wants manageable and predictable memory utilization.
E
mparable to pauses of
> refcounting,
> i.e. it has longer pauses where refcounting had shorter pauses and
> vice versa.
Python's cyclic gc can also cause long pauses if you end up with a
ton of objects in say generation 2, because it takes time just to
traverse them even i
ese Shop seems fine to me (and not just 'cause I came up with
it). You /need/ a little humor and levity in a software project or
it just gets boring.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRTTDc3EjvBPtnXfVAQJojAP+M6HOXbZWMMXqPkVlsSSoBSFrs31L23xv
y+Q
is that no one can agree on how to
> pronounce
> it. (I pronounce it "Python Package Index".)
No no no, it's pronounced "Throatwobbler Mangrove".
speaking-pythonical-ly y'rs,
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Da
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 17, 2006, at 4:28 PM, Terry Reedy wrote:
> Pie/Pi/Py/Pyeshop -- pun intended
>
> Package index (pi) shop
> Python extension/expansion (pye) shop
> Python index of extensions (pie) shop
>
> Take your pick of acronyms, but pie is yummy in about a
standard character used for quotes in e-mails. As a result, intepreter
> sessions might look funky when copy & pasted inside mails.
"Low hanging" as in peaches rotting on the ground? :)
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRW5gZnEjvBPtnX
se generated extensions. Generated
code can be a big time saver while you'r developing the code, but
eventually you have to go digging into it, then it's always way more
painful.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRXHr
a language feature or library
feature. I tend to think the latter is more appropriate given where
Py3k is already headed.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRXQgd3EjvBPtnXfVAQKSaQP/fD1bdfLRnxxeXxAYal6QbLH1nn7fJRtK
wr55zVw8NyQ2qVeIMF3agd+jsWAPWy1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 6, 2006, at 4:36 AM, Jan Grant wrote:
> On Mon, 4 Dec 2006, Barry Warsaw wrote:
>
>> After several years of use, I'm strongly +1 for this feature in some
>> form or another.
>
> I think it's a terrible ide
g supplying the interpolation values rather
than the thing providing the template. You need both sides of the
equation. IME, the template is the generic "machinery, not policy"
part and the substitution supplier is the "policy" part.
- -Barry
-BEGIN PGP SIGNATURE
ieve that most of the SQL wrapper packages for Python
already provide safe prepared statement like functionality, that is
convenient to use.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRXa/y3EjvBPtnXfVAQJXTAP/YjVK4fW0c
g here with $variable in it')
or some day
s = I('some string here with {variable} in it')
And I() is the thing you build the application-specific quoting (or
translating) machinery into. Simple to explain and easy to read and
write!
- -Barry
--
t one external C++ library that really has no need being C++.
It's manageable on Windows and Linux, but some platforms (e.g. starts
with "so" and ends with "is") are really quite painful.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRX1QI
n't going to kill it.
The C and Python versions of some modules are not always identical.
There can be subtle differences and those would need to be addressed
before the Python version could be ditched. E.g. subclass-able
StringIO.
- -Barry
-BEGIN PGP SIGNATURE-
Version: Gnu
it
> here,
> and/or write a PEP.
The nice thing about stdlib reorg is that you can do it now (or at
least get pretty close to the py3k version). Distutils/setuptools,
etc. Implement it now and release it to the Cheeseshop so we can all
see it and try it out.
- -Barry
-BEGIN PG
lt-in? We actually use both, but we use the
C API call much more frequently than the built-in call. I don't
think it would be too painful for us if intern() was removed, but
OTOH if it was stuck in some Python internals module (sys?) and not
kept as a built-in, that would be fine too.
- -
lowing underscores in module names.
I think we just made that rule because we though they looked ugly. I
still think they do, but sometimes they're less ugly than not having
them, especially when you're consistent with the no-mixed-case rule.
- -Barry
-BEGIN PGP SIGNATURE--
use it on all my smaller non-
work related projects now too. I think Bazaar would serve the Python
project well.
http://bazaar-vcs.org
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iQCVAwUBR3PU7HEjvBPtnXfVAQLtMAQAhmRYKr/y8XFXKqh5LWyygErxvldqfXYz
r2dOV5EhEj
ly well, and I personally don't want to contemplate any
> major procedural changes until both 3.0 and 2.6 are out the door.
We'll leave the timing up to Brett and the infrastructure committee,
but IMO, there's no overriding reason to wait. In fact, it would be
better
sist pushing DVCSes whenever I get the
> opportunity. :-P
I know what you mean! Moving to a dvcs can be a life altering event
for a developer :).
> I haven't seen a basic, practical, "vs.-svn" sort of introductory
> article on DVCSes. I wish there was
n
worthy of the term, IMO. Heck, that server isn't even necessary if
you consider bundling branches (not patches!) into an email
"publishing".
> The advantages related to merging are merely "nice" features, not
> critical ones to warrant moving away from sv
s no surprise that nobody
> volunteers.
If Bazaar is chosen, I would volunteer to help with the conversion.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iQCVAwUBR3XH83EjvBPtnXfVAQKVJwP9GkyCg1FaQspez2DeDbjLbnAcxdAwD0aB
WlnPP552jsw
solve a problem that
> I actually ever have. I rarely want to rename files, and renaming
> files in the Python repository requires consensus, anyway, so any
> renaming *should not* be committed along with other changes.
I suspect you'll see quite a bit of renaming during the stdlib
reor
teresting
perspective on the whole setuptools approach and how it interacts (or
doesn't) with the distro packagers.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iQCVAwUBR4IuLnEjvBPtnXfVAQLzQQQAqntqN6JW/WPK5nso/YWj7ytBfgUP7j0H
YxsgYuAzviHg
where a sumo distribution is
needed, but our release process could account for that.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iQCVAwUBR4I8yXEjvBPtnXfVAQJDJwP/RtTksLY6IrCGqlPLgJ/rrFYebMGwbc5Q
Y6vILQ9PTnxniRZuL8PntX8C/ZZgIwW6Zg7NTtUkOplrM23gJ4jm2jO8+CuFe8hE
AuOTf6Jk6Z
, 'xml', 'php'):
I generally prefer the latter but I know folks who prefer the former.
What's interesting is that in both cases we're trying to ask if the
key is a member of a literal set, and to me, it makes no sense for
that literal to be mutable. So I also
g a link to the most recent python3.x.
>>
>> Except it currently does, both during the install from source
>
> Then altinstall should be made the default.
I think this is the best solution. +1
- -Barry
-BEGIN PGP
ommand line
switch to mirror $PYTHONDEBUGGER.
trying-not-to-spray-hydrazine-all-over-you-ly y'rs,
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBR72SZXEjvBPtnXfVAQK7gwP7BKyIMAarMZEPzTQVfR/W8J4KzBEQFhtj
3pLd83I8oQMgP4SD0BapiJZ2BOws3i2TAZ501V8VF8iR50nyNGTYCP4p
lease the last Friday of
every month. For the alphas, it's basically what's in svn. This
gives us some time to experiment with the process out and see if we
like it enough to keep it going through the betas and final releases.
Comments?
- -Barry
-BEGIN PGP SIGNATURE
and simplicity of setting a
break point explicitly in the code (maybe inside a conditional,
etc.). I just want to type less. :)
Well, it was probably a dumb idea anyway born of minor frustration, so
I'll drop it.
- -Barry
-BEGIN PGP SIGNATURE-
Version: G
e release going to make more sense than
> doing binary builds?
It very well might. See Christian Heimes's follow up re: Windows
builds. OTOH, I'm okay if at least for the alphas, the binary builds
lag behind the source releases, though I'd like to get the process as
streaml
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 24, 2008, at 9:19 AM, Christian Heimes wrote:
> Barry Warsaw wrote:
>> I'd also like for us to consider doing regular monthly releases.
>> Several other FLOSS projects I'm involved with are doing this to very
>>
1 - 100 of 407 matches
Mail list logo
