On Thu, 2006-03-23 at 14:52 -0500, Jim Fulton wrote:
> If we are dead set on making these methods return iterators, I'd really like
> to see a way to either get non-iterators by calling a method or see some
> new facilities in the iterators returned. Perhaps these iterators
> could have a method
On Thu, 2006-03-23 at 16:02 -0800, Brett Cannon wrote:
> I don't think things are going to be broken gratuitously.
However, I hope we don't throw out clearly beneficial improvements for
backward compatibility's sake. But yes, all things being equal, if it
comes down to a tie-breaker then backwar
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
> constraints you have only got an iterator.
Which can happen quite often actually. Perhaps making the original
object available as an attribute of the iterator can help
On Fri, 2006-03-24 at 19:41 +1200, Greg Ewing wrote:
> Guido van Rossum wrote:
>
> > That won't go away for me (Google's settings default to TWO-space
> > indents :-( ) but I agree with the 4-space indent -- eventually.
>
> If we standardised on all-tabs, people could set their
> editors to displ
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
On Fri, 2006-03-24 at 11:49 -0500, Kevin Jacobs wrote:
> On 3/24/06, Charles Cazabon <[EMAIL PROTECTED]> wrote:
> like 8-space indents would then start to argue vociferously
> about how many
> levels of indentation are acceptable given an
> 80-character-wide source
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
signature.asc
Descr
On Mon, 2006-04-03 at 00:44 +0200, Giovanni Bajo wrote:
> Not me. Surely it'd help if its documentation explained why on earth it has
> been introduced. There are no apparent advantages over the builtin %s
> operator,
> at first sight. Nothing worth using a non-standard non-builtin substitution
>
On Sun, 2006-04-02 at 23:26 -0500, Ian Bicking wrote:
> Georg Brandl wrote:
> > BTW, has anyone seen string.Template being used somewhere?
>
> I use it from time to time, usually when formatting user-provided
> strings (because "%(foo)s" is not very pleasant or easy-to-explain
> compared to "$fo
On Mon, 2006-04-03 at 12:06 +0200, Giovanni Bajo wrote:
> Yes, I said "documentation" for a reason. Since when people have to go looking
> in PEPs for rationale of a module? string.Template introduces a very clear
> TOOWTDI conflict, I think the documentation should mention and try to explain
> it
On Mon, 2006-04-03 at 23:43 +1000, Nick Coghlan wrote:
> What do you think of a "format" builtin function that accepts the format as
> the first argument (similar to printf).
>
> The version on my harddrive permits positional arguments via $1, $2, etc, as
> well as string formatting (by stickin
On Mon, 2006-04-03 at 11:13 -0500, Ian Bicking wrote:
> assert path.startswith(prefix), (
> "%r should start with %r" % (path, prefix))
> assert path.startswith(prefix), (
> $"${repr(path)} should start with ${repr(prefix)}")
> assert path.startswith(prefix), (
> "$path should start
On Mon, 2006-04-03 at 10:44 -0700, Crutcher Dunnavant wrote:
> Well, what if we added '%{expression}s' as a formating type?
> This would make your example:
>
> print _("%{user}s is not a member of the %{listname}s mailing list")
>
> or even:
>
> print _("%{utils.websafe(form.get('user'))}s is n
On Mon, 2006-04-03 at 13:12 -0500, Ian Bicking wrote:
> Even what Mailman
> does is potentially slightly unsafe if they were to accept input to _()
> from untrusted sources, though exploiting str() is rather hard, and
> Mailman presumably has at least a moderate amoung of trust for translators.
On Mon, 2006-04-03 at 13:51 -0500, Ian Bicking wrote:
> > No it shouldn't be. format() should be a varargs function; __rmod__
> > takes a single argument which may be a tuple. Also, format() could
> > take keyword args in case the string contains named format, so I can
> > write e.g. "%(foo)s".for
On Mon, 2006-04-03 at 15:23 -0500, Ian Bicking wrote:
> This is all wandering off-topic, except that all these cases make me
> think that different kinds of wrapping are very useful. For instance,
> if you want to make sure everything is quoted before being inserted:
>
> class EscapingWrapper:
On Tue, 2006-04-04 at 13:27 +1200, Greg Ewing wrote:
> If I were designing a formatting system from scratch,
> I think I'd separate the issue of formatting numbers into
> strings from the issue of inserting strings into other
> strings.
This really is a key observation. PEP 292 tried to make ins
On Tue, 2006-04-04 at 10:41 -0500, Ian Bicking wrote:
> A $ prefix would act at parse time, i.e., $"answer: $answer" would be
> equivalent to ("answer: " + str(answer)).
Wouldn't it be equivalent to string.Template("answer: $answer") ? In
any event...
> Though I also agree that $"answer: $answ
On Mon, 2006-04-03 at 22:18 -0400, Adam DePrince wrote:
> Worse are the maintance problems when you have to change your
> expression ... inside every translation of your string.
You're right, that's far far worse. One thing about i18n is that it
introduces huge inertia against changing any hum
On Tue, 2006-04-04 at 14:28 +1200, Greg Ewing wrote:
> If we're going to encourage use of named arguments
> (which I think we should) I think we also need to
> get rid of the need for %(foo)s constructs, which
> are extremely error-prone and hard to read.
In general, I agree.
> I'm -0.7 on havin
On Tue, 2006-04-04 at 09:57 -0700, Guido van Rossum wrote:
> On 4/3/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> > I've been thinking that `hash` could be an attribute (or property if it
> > needs to be calculated on-the-fly) rather than the current method call.
> >
> > Or it could be an
On Apr 4, 2006, at 7:17 PM, Ian Bicking wrote:
>
> These don't quite work with string.Template, because ${...} has the
> same content constraints that $... has, so you can't easily put
> extended expressions in there. I could have sworn I opened an SF
> bug on this, but it appears not. But
On Apr 4, 2006, at 7:44 PM, Greg Ewing wrote:
> I'm more interested in long-term readability
> and maintainability than in pandering to one-off
> impressions when coming from another language.
>
> I don't believe they would have any difficulty
> "getting" this, anyway. Can you honestly say
> that
On Apr 4, 2006, at 8:38 PM, Greg Ewing wrote:
> Ian Bicking wrote:
>
>> Using {} instead of $/${} doesn't seem like a big win.
>
> Perhaps this is where we differ. To me it
> *does* make quite a substantial difference
> to readability -- easily enough to override
> whatever small advantage there
On Mon, 2006-04-10 at 12:16 -0400, Kendall Clark wrote:
> I don't know if the Ruby syntax for symbols, :foo, will work in
> Python (though I think visually it's a good thing), but it would be
> really nice to have symbols with *some* syntax in Python 3000.
To be fair, I think Ruby stole the i
On Tue, 2006-04-11 at 10:47 +0400, Oleg Broytmann wrote:
> On Tue, Apr 11, 2006 at 12:58:47AM -0400, Kendall Clark wrote:
> > Hmm. Tastes vary, obviously. I don't consider using ? to signal
> > boolean returning functions or methods to be random.
>
>They look ugly in expressions:
>
> if pyt
-1 on removing self from method defs. I always make the opposite
mistake from Ian when moving from Python to C++ or Java. :)
On Thu, 2006-04-13 at 12:59 -0500, Ian Bicking wrote:
> My own interpretation of self-related criticism is that people get
> bothered with all the "self"s from their expe
On Thu, 2006-04-13 at 13:01 -0500, Ian Bicking wrote:
> I propose that strings (unicode/text) shouldn't be iterable.
+1. I think I've mentioned before that we have a particular choke point
that may get scalars or sequences, but that everything coming out of
that choke point is guaranteed to be a
On Mon, 2006-04-17 at 14:01 -0700, Raymond Hettinger wrote:
> -1 on making strings non-iterable. The cure is worse than the disease.
> In ML, characters and strings are different datatypes and it is a
> complete PITA. I suspect that making strings non-iterable would make
> the language more
On Mon, 2006-04-17 at 16:08 -0700, Brian Harring wrote:
> The issue I'm seeing is that the wart you're pointing at is a general
> issue not limited to strings- everyone sooner or later has flattening
> code that hits the "recursively iterate over this container, except
> for instances of these
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
signature.asc
Descri
On Fri, 2006-04-21 at 13:25 -0500, Ian Bicking wrote:
> While I've argued in an earlier thread that $var is more conventional,
> honestly I don't care (except that %(var)s is not very nice). A couple
> other people also preferred $var, but I don't know if they have
> particularly strong opinio
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
signature.asc
Description: Th
On Mon, 2006-04-24 at 10:16 -0400, Greg Wilson wrote:
> I'm sure we can work something out --- I agree, {} for empty set and {:}
> for empty dict would be ideal, were it not for backward compatibility.
I dunno, the more I write dict() and set() the more I kind of like them
rather the literal alte
On Mon, 2006-04-24 at 11:18 -0700, Guido van Rossum wrote:
> > Hmmm... Should we see this as official confirmation that PEP 7 is going to
> > go to 4-space indents instead of tab ones, or is it just an editor
> > accidentily left in Google-indent mode? (I think I prefer the former ;)
>
> The form
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
(defconst py3k-st
On Mon, 2006-04-24 at 11:44 -0700, Guido van Rossum wrote:
> Doesn't have to be a flag day -- we can reformat code
> opportunistically whenever there's no hope of ever doing merges from
> 2.x.
>
> I do plan that within one file we'll stick to style consistency.
Sounds good to me. I guess when s
On Tue, 2006-04-25 at 15:48 -0700, Aahz wrote:
> My opinion: if we were designing Python from scratch right now, we might
> well consider having only set literals and not dict literals. However,
> I don't think we can have both set and dict literals, and I think that
> removing dict literals (or
On Wed, 2006-04-26 at 08:03 +, Talin wrote:
> In my experience dict literals are far more useful than set literals. In
> fact, I
> don't think I've ever made a set literal. The only syntactical short cut that
> I
> would find useful for a set would be "new empty set", for which I think
> "s
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
Description: This is a d
On Thu, 2006-04-27 at 10:08 -0700, Aahz wrote:
> While I hate the way it looks, I never have gotten mixed up about the
> order of arguments since switching to ''.join(l).
Which is why
EMPTYSTRING = ''
...
EMPTYSTRING.join(seq)
looks much better. But hey, yeah, a join() builtin would be fine
On Thu, 2006-04-27 at 11:49 -0700, Raymond Hettinger wrote:
> [pep-3100 checkin]
> > {F(x) for x in S if P(x)} means set(F(x) for x in S if P(x)).
>
> I presume this means that there will never be dictionary
> comprehensions (as they would aspire to have an identical notation).
>
>
>
> > Ther
On Thu, 2006-04-27 at 12:57 -0600, Steven Bethard wrote:
> On 4/27/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > [pep-3100 checkin]
> > > {F(x) for x in S if P(x)} means set(F(x) for x in S if P(x)).
> >
> > I presume this means that there will never be dictionary
> > comprehensions (as the
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.
On Thu, 2006-04-27 at 16:05 -0700, Eli Stevens (WG.c) wrote:
> I think you'd have to create a tuple, and convert it to a set on the
> fly. Which should x be in the following:
>
> x = (1, 2, 1)
> dictOfCallables["foo"](x)
Well here's another nutty idea. We actually have two ways to create
lite
On Thu, 2006-04-27 at 10:18 -0700, Alex Martelli wrote:
> > ''.join(seq) == join('', seq)
>
> I think I would prefer a signature of:
> join(seq, joiner='')
Except that I think it would be a mistake to have that and keep
the .join() method on strings because that would increase the confusion
On Tue, 2006-05-02 at 12:05 -0700, Raymond Hettinger wrote:
> I think Guido had the best solution. Use set() for empty sets, use {}
> for empty dicts, use {genexp} for set comprehensions/displays, use
> {1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict
> literals. We can alwa
On Mon, 2006-05-08 at 15:55 +0200, Thomas Wouters wrote:
> Dare I suggest you convince Guido not to remove callable(), then? That
> is, after all, what this discussion is about.
We use callable() and PyCallable_Check() in a couple of places. I'm not
sure that our uses are enough to keep these al
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
On Mon, 2006-05-08 at 20:51 -0700, Guido van Rossum wrote:
> Well, personally, I don't see the advantage. I don't see the point of
> having lots of different exception types that say "you made a
> programming error" in different ways, and I severely doubt the
> usefulness of being able to distingui
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 5, 2006, at 6:54 AM, Guido van Rossum wrote:
> So, my proposal is to give up on static, accept PEP 3103 with the
> following options:
> - Syntax alternative 2+B (unindented cases, 'case in ...' for
> multiple cases).
> - Semantics option
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 20, 2006, at 11:53 AM, Guido van Rossum wrote:
> The 'with' syntax is attractive because it will flag all unconverted
> code as a syntax error.
>
> I wonder if "raise ValueError" should still be allowed (as equivalent
> to "raise ValueError()")
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]
http://mail.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 23 Aug 2006 08:18:03 -0700
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> That's too narrow a view on the language. Surely the built-in types
> (especially those with direct compiler support, like literal
> notations) are part of the language
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 28, 2006, at 9:20 PM, Greg Ewing wrote:
> I'm also not all that happy about forcing slice indices to
> be ints. Traditionally they are, but someone might want to
> define a class that uses them in a more general way.
In fact, we do. Our appli
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 29, 2006, at 5:01 PM, Jim Jewett wrote:
> Why is it essential that string views be a different type, rather than
> an internal implementation detail, like long vs int? Today's strings
> can already return a new object or an existing one which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 30, 2006, at 5:57 PM, Guido van Rossum wrote:
> Perhaps a compromise could be to add a keyword parameter to request
> such an exception? (We could even add three options: truncate, pad,
> error, with truncate being the default, and pad being th
-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.
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 31, 2006, at 12:12 PM, Raymond Hettinger wrote:
> It is important that zip() be left as dirt simple as possible. In
> the tutorial (section 5.6), we're able to use short, simple
> examples to teach all of the fundamental looping techniques
On Sep 1, 2006, at 2:49 AM, Fredrik Lundh wrote:
> Guido van Rossum wrote:
>
>> I think it would be best to do this as a CPython configuration option
>> just like it's done today. You can choose 4-byte or 2-byte Unicode
>> (essentially UCS-4 or UTF-16) in order to be compatible with other
>> pack
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 10, 2006, at 1:53 PM, Anders J. Munch wrote:
> I say drop seek_cur and seek_end altogether, and keep only absolute
> seek.
I was just looking through some of our elf/dwarf parsing code and we
use seek_cur quite a bit. Not that it couldn't b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 18, 2006, at 12:27 PM, Marcin 'Qrczak' Kowalczyk wrote:
> "Adam Olsen" <[EMAIL PROTECTED]> writes:
>
>> * Bolt-on tracing GC such as Boehm-Demers-Weiser. Totally
>> unsupported
>> by the C standards and changes cache characteristics that CPy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 18, 2006, at 3:56 PM, Raymond Hettinger wrote:
> * An easier C API would significantly benefit the language in terms of
> more extensions being available and in terms of increased reliability
> for those extensions. The current refcount scheme
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 19, 2006, at 12:05 PM, Brian Quinlan wrote:
> Marcin 'Qrczak' Kowalczyk wrote:
>> Brian Quinlan <[EMAIL PROTECTED]> writes:
>>
Reference counting is inefficient, doesn't by itself handle cycles,
and is impractical to combine with thre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 22, 2006, at 7:54 AM, Marcin 'Qrczak' Kowalczyk wrote:
> Greg Ewing <[EMAIL PROTECTED]> writes:
>
>> I know. What I mean to say, I think, is can it be designed so that
>> there cannot be any pauses longer than there would have been if
>> freein
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 16, 2006, at 9:28 PM, Fred L. Drake, Jr. wrote:
> Which is really, really, REALLY sad. The "Cheese Shop" name may
> reflect the
> proper cultural bias toward Monty Python, but it's a sure way to
> alienate
> people by presenting the hard w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 17, 2006, at 1:54 PM, Fred L. Drake, Jr. wrote:
> I seem to recall Richard Jones saying he pronounces it "pippy",
> which I never
> could understand based on the spelling.
>
> So, the biggest problem "PyPI" is that no one can agree on how to
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 29, 2006, at 7:51 PM, Giovanni Bajo wrote:
> it's a minor issue, but I was wondering if the interpreter prompt
> could be
> changed in Py3K. The current prompt is ">>>" which happens to match
> the
> standard character used for quotes in e-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 2, 2006, at 3:58 PM, Neil Toronto wrote:
> One potential problem with this idea is that you can't drop into C
> code
> without calling an external C function, which may not be acceptable in
> some instances. Another is that if you want to ana
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 4, 2006, at 5:08 AM, Ben Wing wrote:
> i see in PEP 3101 that there's some work going on to fix up the string
> formatting capabilities of python. it looks good to me but it still
> doesn't really address the lack of a simple interpolated stri
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 6, 2006, at 5:02 AM, Ka-Ping Yee wrote:
I agree with where Ka-Ping is headed...
> Where does this design constraint take us?
>
> One possibility it suggests is that the interpolation function could
> be generic, allowing the formatting templat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 6, 2006, at 5:24 AM, Jan Grant wrote:
> PS. IF generic functions (operators) could be sensitive to return
> types
> and IF python6k supported a complex type inference mechanism (possibly
> including automatic coercion), then one might be able
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 6, 2006, at 7:04 AM, Fredrik Lundh wrote:
> btw, note that you can get the same behaviour with today's Python:
>
> s = I("some string here with ", variable, " in it")
>
Or even
s = I('some string here with $variable in it')
or some day
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 10, 2006, at 9:57 PM, Neil Toronto wrote:
> Martin v. Löwis wrote:
>> Not having to repeat struct has no ABI impact.
>
> Yes! Switch to C++! Down with struct!
>
> No, I *don't* have anything useful to add to the discussion, in fact.
I know thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 11, 2006, at 6:50 PM, Greg Ewing wrote:
> I say stop worrying and ditch the Python version. An
> alternative Python implementation is going to have to
> provide implementations of all the existing C-only
> modules. A few more isn't going to kil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 19, 2006, at 12:10 AM, Josiah Carlson wrote:
>> I feel strongly that modules os, os.path, shutil, etc. that deal with
>> files and paths need reorganizing.
>
> So think about what you think would make sense, perhaps propose it
> here,
> and/o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 19, 2006, at 1:03 PM, Guido van Rossum wrote:
> On 12/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Georg Brandl wrote:
>>
>>> so what about id() and intern(). Care to pronounce?
>>
>> moving/removing id()? please don't do that; id(obj) a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 21, 2006, at 5:53 PM, Mike Orr wrote:
> On 12/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 12/21/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>>> not using underscores in package names makes a certain sense, but
>>> not allowing the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 26, 2007, at 8:20 PM, Brett Cannon wrote:
> It is nice. Once Mercurial hits version 1.0 I am going to look at
> whether it is reasonable to move Python to hg or bzr to make it easier
> for people to do development on their own machines with lo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 28, 2007, at 11:49 AM, Nick Coghlan wrote:
> For migrating from a centralised to a distributed VCS though, since
> the
> PSF repository is the upstream of all of the derived builds, it
> doesn't
> really gain any major benefits from the swi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 28, 2007, at 9:30 AM, Matt Nordhoff wrote:
> Bzr has a nice UI and is cross-platform (and has great dumb server
> (HTTP, SFTP, FTP) support), but is slow (not a problem on non-huge
> projects, and it's getting better).
In fact, my /personal/ o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 28, 2007, at 12:56 PM, Adam Olsen wrote:
> Providing official mirrors of all (or at least several important)
> svn branches in popular DVCS tools would be sufficient. Better, if
> you consider that you can do several tools simultaneously,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 28, 2007, at 8:24 PM, Martin v. Löwis wrote:
>> We'll leave the timing up to Brett and the infrastructure committee,
>> but IMO, there's no overriding reason to wait.
>
> *That* is the major overriding reason: lack of volunteers. Any kind
> of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 28, 2007, at 8:28 PM, Martin v. Löwis wrote:
>> Here's a simple one: how about not having your vcs force you to
>> commit
>> changes to a public repository before you're ready? Under svn if you
>> modify a file and before you commit it decid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 6, 2008, at 1:35 PM, Jim Fulton wrote:
> Really, I'd like to see a much smaller standard library. IMO, pickle
> isn't essential enough to be part of the standard library and I'd be
> happy to see pickle become a separate project. I'd prefer to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 7, 2008, at 9:41 AM, Paul Moore wrote:
> If there were two officially distributed versions of Python,
> python-std (basically what we have now) and a python-lite without the
> full stdlib, then I could probably live with the situation (but the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 24, 2008, at 7:12 PM, Raymond Hettinger wrote:
>> Looking over the code base, frozensets are used rarely.
>> So I don't think this is warranted.
>
> There is no shortage for perfect use cases in the form:
>
> if urlext in {'html', 'xml', 'php
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 4, 2008, at 6:20 PM, Stephen J. Turnbull wrote:
>>> On the contrary, Python 3.1 itself may be buggy. I do not think is
>>> it appropriate for the Python installer to make that decision for
>>> the user by creating a link to the most recent pyt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I know this will get shot down like a Navy missile aimed at an errant
spy satellite, but I'm going to suggest it anyway.
Several of us have been talking about merging the two Emacs Python
modes and this prompted a discussion of Ken Manheimer's exc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I've volunteered to be the release manager for Python 2.6 and 3.0.
It's been several years since I've RM'd a Python release, and I'm
happy to do it again (he says while the medication is still
working :). I would like to get the n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 21, 2008, at 10:23 AM, Jean-Paul Calderone wrote:
> Wouldn't a less invasive solution be to make pdb better? In
> particular,
> to make `breakpoint´ actually reliably set a breakpoint?
Maybe, although I like the directness and simplicity of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 22, 2008, at 6:54 PM, Brett Cannon wrote:
>> Hi everyone,
>>
>> I've volunteered to be the release manager for Python 2.6 and 3.0.
>> It's been several years since I've RM'd a Python release, and I'm
>> happy to do it again (he says while the m
-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
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 24, 2008, at 1:57 PM, Martin v. Löwis wrote:
>> 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
1 - 100 of 406 matches
Mail list logo
