Lino Mastrodomenico writes:
> It's a know problem with Shift-JIS and was fixed in UTF-8.
It was fixed in EUC before Shift-JIS was invented by Microsoft or Big5
was invented by the Taiwanese clone makers. Guido's not the only
language designer with a time machine
__
"Martin v. Löwis" writes:
> > Yeah, yeah, this is the same old same old from PEP 3131. Anything
> > that handles the various attacks based on ASCII-alike characters
> > should at least rule out invalid Unicode, too!
> >
> > And where is this U+DC2F supposed to be coming from, anyway? The
"Martin v. Löwis" writes:
> > Now, with Python's file system encoding == UTF-8 or any packed EUC,
> > and more than a handful of Shift JIS or Big5 characters in file names,
> > one is *almost certain* to encounter ASCII as the second byte of a
> > multibyte sequence. PEP 383 can't handle this
Walter Dörwald writes:
> "surrogatepass" (for the "don't complain about lone half surrogates"
> handler) and "surrogatereplace" sound OK to me. However the other
> "...replace" handlers are destructive (i.e. when such a "...replace"
> handler is used for encoding, decoding will not produce the
M.-A. Lemburg writes:
> I'd use "allowlonesurrogates" as name for the "surrogates" error
> handler and "lonesurrogatereplace" for the "utf8b" one.
+1
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Antoine Pitrou writes:
> Just food for thought here, but seeing how 3.1 is going to be a
> real featureful schedule despite being released shortly after 3.0,
> wouldn't it make sense to tighten future release planning a little?
With all due respect, it's easy and natural to have a short,
featu
Tennessee Leeuwenburg writes:
> Can I ask if there's any sense in pursuing a release schedule which
> is slow for whatever might be deemed the "most core modules" but
> faster for "less core modules"?
I think you need to be more specific about how many levels of "fast"
there should be, and why
Benjamin Peterson writes:
> 2009/5/20 :
>
> > I suspect it's not really germane to this discussion but if the
> > incref/decref functions were defined as inline would that effectively be
> > like using the macro versions vis a vis ABI compatibility?
>
> The code would be inlined into appl
Aahz writes:
> On Tue, Jun 02, 2009, Guido van Rossum wrote:
> >
> > I hope we can learn from this.
>
> I'm not thrilled with adding more process just because we had a problem
> here, and the only obvious solution I see is to require a PEP every time
> a module is added. Based on what I'v
Antoine Pitrou writes:
> Terry Reedy udel.edu> writes:
> >
> > I watched and was greatly impressed by the video demo of Google's new
> > Wave collaborative communication system. I believe it would/will help
> > with some of the chronic problems we (and others) have.
>
> I really don't
"Martin v. Löwis" writes:
> I'm not sure that the concept of a "trunk" branch still exists in
> Mercurial. PEP 385 apparently doesn't have resolved the branch strategy
> for Mercurial yet. With cloned branches, I think the concept of a
> "trunk" becomes irrelevant.
"Trunk" exists as a technic
Lennart Regebro writes:
> 2009/6/7 Stephen J. Turnbull :
> > Python's 2.x/py3k division is a tour de force; I still can't believe
> > my eyes that you've pulled it off.
>
> Well, It's not pulled off until Python 3 has surpassed Python 2 in
> usa
Jesse Noller writes:
> Any thoughts? Does anyone hate this idea with the power of a thousand suns?
If somebody has the power of 1000 Suns at their disposal, maybe they
can contribute a few buildbots?
Wishful-thinking-is-the-order-of-the-day-ly y'rs,
Tarek Ziadé writes:
> On Wed, Jul 1, 2009 at 1:44 PM, Paul Moore wrote:
> > General rule - don't document (and commit yourself to) any
> > internal details that the user can't access from the public
> > API. It just makes backward compatibility harder to maintain.
>
> The purpose is to prov
Dirkjan Ochtman writes:
> Mercurial has two basic ways of using branches: cloned branches, where
> each branch is kept in a separate repository, and named branches,
> where each revision keeps metadata to note on which branch it belongs.
> The former makes it easier to distinguish branches, at
Dirkjan Ochtman writes:
> On Fri, Jul 3, 2009 at 15:29, Stephen J. Turnbull wrote:
> > I'll have to try them again now that 1.3 is out, but I found Mercurial
> > named branches fundamentally unsuited to release management.
>
> Can you explain why, please? It
Nick Coghlan writes:
> I'm not clear on the rationale for the explicit CRLF line ending on the
> email test message, but I would guess it is to ensure that the email
> module can handle CRLF line endings correctly regardless of platform.
IIRC, that's just the standard for text email. Lines mu
P.J. Eby writes:
> Wouldn't the simple thing to do in Mercurial, just be to use
> different repositories for long-lived branches? I mean, if you're
> not merging them that much anyway, what's the point?
I basically agree with that, and so does Dirkjan, I think. I'm not
sure why he brought
Georg Brandl writes:
> What I really want to see is the common-subset approach for
> maintenance branches.
IMO, this unfortunately unlikely to work as you seem to expect, for a
two technical reasons and for a social reason. The first technical
reason is that a maintenance branch really is a br
Tarek Ziadé writes:
> On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote:
> > No one expects the package inquisition. ;-)
> Sorry, i've looked in the english dictionary but I don't get this one.
I think that far more important than PEP 385 conversion of Roundup and
other utilities to recognize
R. David Murray writes:
> On Tue, 7 Jul 2009 at 15:26, M.-A. Lemburg wrote:
> > I've seen a few discussions about this, but no final statement
> > of what strategy to follow and whether hg makes this easier (AFAIR,
> > that was the main argument for switching to hg).
Yes, yes, yes, and no. I
Eric Smith writes:
> But I think we've veered into metadata that describes what has been
> installed. I don't think that's so useful. As I've said, this is private
> to the installers. If 2 installers want to communicate with each other
> about what they've installed, then they can agree on
Floris Bruynooghe writes:
> [dist-packages] is a pretty neat solution to the problem.
To what problem? I admit I am no expert on Python packaging, but my
experience with XEmacs suggests that this is the distro trying to help
with a *set* of problems that the user/sysadmins really should be
hand
David Lyon writes:
> On Fri, 24 Jul 2009 17:08:32 +0100, Paul Moore wrote:
> > I read this as meaning that David was proposing to ship a built
> > application (on Windows, bundled up with something like py2exe, I
> > guess) and any supporting DLLs such as the wxWindows ones would be
> > bundl
"Martin v. Löwis" writes:
> > pythonpkgmgr is not so different to that. And the idea behind it is
> > to bring consistancy in package management across the different
> > platforms.
>
> At the cost of being inconsistent within a platform.
Indeed, and that seems to be one of the really big s
David Lyon writes:
> On Mon, 27 Jul 2009 11:18:25 +0900, "Stephen J. Turnbull"
> wrote:
> > [1] on
> > my part") and sysadmin goals ("something that works and plays nicely
> > with the rest of the system").
> >
> > pytho
David Lyon writes:
> It manages local developer modules for python 2.6+.
> pythonpkgmgr is aimed at featherweight users.
You were talking about "developers", but now they're "featherweight
users"? I'm sorry, but the more you post, the less I like the idea of
including it with Python. Please
Mark Hammond writes:
> I'm not sure what point you are trying to make, but I believe it *is*
> possible for a solution to be found here which will keep Windows users
> happy. I'm guessing you haven't had much practical experience with this
> problem, so probably don't see this is clearly a
Oleg Broytmann writes:
>Dirkjan, how does Mercurial handles charsets? If I have three files in
> my repository - one in utf-8, another in koi8-r, and the third in cp1251
> encoding - I certainly don't want to convert them back and force, but I
> want hg web interface to provide charset in
"Martin v. Löwis" writes:
> > I don't see any good reason for having any encodings but UTF-8 in
> > Python's.
>
> Just in case my previous message gets overlooked: PEP 8 mandates Latin-1
> for Python 2.x source code (except for files that test PEP 263).
You're right, sorry for the misinform
Mark Hammond writes:
> On 6/08/2009 12:28 AM, Stephen J. Turnbull wrote:
> > I think the implication is obvious. There will be no good solution
> > until Windows users develop it. I don't see a good reason to wait for
> > that.
> My conclusion is different. I
"Martin v. Löwis" writes:
> > This is simply false AFAICS. There was little participation on this
> > particular issue during PEP 374 that I can recall. Now that it is
> > clearly an issue after all, it's still early in the PEP 385 process.
> > Martin has already picked up the ball on EOL sup
Steven D'Aprano writes:
> It's not immediately obvious to me why the last expression should be
> given that privileged rule. Why not the first expression?
Or the second, for that matter. So find a large body of Lisp code and
run "grep -r prog1 | wc", "grep -r prog2 | wc", and "grep -r progn |
Mark Hammond writes:
> * Add support for versioned 'filter rules' - eg, /.hgfilters or similar.
>
> * This might be pushing my luck, but: add 'defensive' support to core hg
> for this feature - if /.hgfilters exists, hg should refuse to operate on
> the working tree unless the win32text ex
Nick Coghlan writes:
> Stephen J. Turnbull wrote:
> > Note that Bazaar is currently discussing some similar policies. I
> > think the name they have settled on is ".bzrrules". Maybe .hgrules is
> > a better name.
>
> So it would be .hgrules/? Wi
Mark Hammond writes:
> Something like ~/.hgrules having:
Surely you mean $PROJECTROOT/.hgrules?
> [config] # or maybe [rules] ?
> required_extensions = win32text, some_pydev_specific_extension
[extensions]
required_for_commit = win32text,some_other_ext
That might require a change to hg's i
Mark Hammond writes:
> On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
> Possibly - although I would expect the existing section names be reused
> when applied to a versioned file, I'd be more than happy for the hg guys
> to declare new names are appropriate for this.
I
Dirkjan Ochtman writes:
> [Clients] cannot be trusted (e.g. I might put a win32text stub in
> there somewhere that does nothing).
Heck, just edit the .hgrules file, and do a Houdini on any and all
handcuffs.
Don't trust software, trust people -- but help them avoid thoughtless
mistakes.
__
Bugbee, Larry writes:
> My original post was intended to increase the awareness in those
> thinking encrypted ZIP files will 1) be easy, 2) afford the
> protection they desire, and 3) not lead others into a sense of
> false security.
All good points, but note that (even without the DMCA) at l
Ben Finney writes:
> A pity, since the entire point of Design Patterns is to give us a
> vocabulary of terms to use that enable these concepts to be communicated
> *without* continually re-defining them. To that extent, then, they fail
> their purpose.
Of course not! There will always be chi
Chris Withers writes:
> > How can you be certain that any string is UTF-8 when doing any
> > reasonable IO?
>
> Careful checking, and a knowledge for people working on the app's
> development that anything else will result in severe pain, both physical
> and mental ;-)
If you're *that* c
Antoine Pitrou writes:
> > In addition, a DVCS brings in another problem dimension: when people
> > push their changes, they have *already* committed them - and perhaps not
> > even they, but a contributor from which they had been pulling changes.
> > The bogus change may have been weeks ago,
"Martin v. Löwis" writes:
> This is what I refer to as YAGNI. Subversion has LF as the internal
> storage, and, IIRC, so does CVS. I don't think there is any precedence
> for wanting something else - and frankly, I can't see how repository
> storage would matter.
Well, internally you could us
Dirkjan Ochtman writes:
> On 05/09/2009 16:59, Stephen J. Turnbull wrote:
> > git has a nice filter-branch command, which would allow you to
> > automatically repair the problem (it works basically by checking out
> > each changeset and rerecording it with the appr
Paul Moore writes:
> The result is that user workspaces *may* (quite probably, will)
> contain files with a mixture of line endings if care is not taken.
Yes. Under your "fixed-EOL-files-are-binary" scheme, this is
guaranteed for Unix systems.
> As regards (1), I assume that for "text" files
Antoine Pitrou writes:
> Speaking as a non-network specialist, it actually looks logical to
> me to be given an address if I iterate over a network (the same way
> that, if I iterate on a list, I get individual elements, not
> 1-element sublists).
But if you iterate over a string you get one
Scott Dial writes:
> ipaddr.IPv4Network('1.1.1.0/24')[0] == ipaddr.IPv4Network('1.1.1.0/24')
So foo returns True?
def foo():
a = ipaddr.IPv4Network('1.1.1.0/24')
return a[0] == a
That seems ... weird. Maybe you committed a typo?
___
Python
I haven't looked closedly at the reference implementation, and my
experience is small. So take this as "POLA to the naive new user of
the API" discussion.
Scott Dial writes:
> This example here solidifies my support of RDM's suggestion of there
> being 3 types:
>
> IPv4Address
> IP
Antoine Pitrou writes:
> > An IPv4Address with 'network' and 'mask' attributes that could be
> > None would also not complicate the API, IMO, and would handle both
> > of these use cases.
>
> But it would be confusing and conceptually bizarre, because an address (in
> usually accepted termi
Andrew McNamara writes:
> As the module stands, we have a pair of address-without-mask classes
> called *Address, and a pair of address-with-mask classes called
> *Network. So, sometimes when you want to record an *address* you use
> a class called Network, and that class comes with a behaviou
Andrew McNamara writes:
> Conceptually, you sometimes need a bare address, and other times,
> you need an address with an associated network (host interface
> configs, router configs, etc). By AddressWithMask, I really mean
> AddressWithEnoughInformationToDeriveNetworkWhenNeeded. Conveniently,
Antoine Pitrou writes:
> James Y Knight fuhm.net> writes:
> >
> > Why are you just making things up? There is a *vast* amount of
> > precedent for how file operations should work. Python should follow
> > that precedent and do like POSIX unless there's a compelling reason
> > not to.
Antoine Pitrou writes:
> I don't believe that POSIX compliance is a sufficient argument to ask
> someone to shut up in the discussion of a cross-platform API. Which is
> more or less what James' answer was trying to do.
No, as I read it, James said, "when there's precedent, even a
standard,
Brett Cannon writes:
> OK, stop before it gets any nastier as your email already sounds
> rude
Rude, yes, but not entirely lacking in truth. Tarek's post to Python-
Dev *is* a mess from the point of view of English and organization --
it's *way* below Tarek's normal command of the language. G
Tarek Ziadé writes:
> On Wed, Sep 23, 2009 at 9:03 AM, Stephen J. Turnbull
> wrote:
> > At the very least, that would have kept this discussion on Distutils-
> > SIG, and Chris couldn't be accused of trying to make an end run around
> > that process. I suggest
Antoine Pitrou writes:
> There was a proposal to have a separate parse_address_and_mask
> method which would return a (Address, Network) tuple, I still don't
> know why you don't seem to consider it seriously, rather than
> trying to make the Network class a kind of all-in-one type
> conflati
Guido van Rossum writes:
> I don't doubt that Peter has a use case for denormalized IPNetwork
> objects.
If you know what it is, would you please describe it, or say "that's
proprietary"? Peter hasn't done either, despite repeated requests.
> I do note that if Peter's use case is at all comm
Let me first say that the module is overall quite nice; the
implementation seems concise and very efficient, and the API is
well-balanced. I'm sorry there's been such controversy (and for my
part in it, as I managed to completely misunderstand what you
absolutely require), when AFAICT the only "li
Greg Ewing writes:
> Peter Moody wrote:
>
> > I've mentioned at least once (and others have mentioned as well) that
> > it's very common, when describing the ip address/prefix of a NIC to
> > write, "192.168.1.100/24"
>
> Yes, but if you want to *retain* all of that information,
> the obj
Peter Moody writes:
> > > this is interesting. I would be open to doing this and making __lt__,
> > > __gt__, __eq__ and friends do the non-ip comparing by default. would
> > > this be sufficient or does the fact that the network has the .ip
> > > attribute break something pythonic?
> >
Mark Dickinson writes:
> >> Please could someone who understands the uses of IPNetwork
> >> better than I do explain why the following wouldn't be a
> >> significant problem, if __eq__ and __hash__ were modified to
> >> disregard the .ip attribute as suggested:
> > linus = IPv4Network('1
Daniel Stutzbach writes:
> People have voiced support for the IPNetwork class
The obvious use cases are
1. parsing and validating strings that purport to describe networks,
2. providing a received for the result of a function that deduces the
network from an arbitrary address and a mask
Nick Coghlan writes:
> However, while I'd still be a little happier if the .ip attribute
> went away all together and another means was found to conveniently
> associate an IPAddress and an IPNetwork, keeping it doesn't bother
> me anywhere near as much as having network equivalence defined in
Tarek Ziadé writes:
> Maybe I should blog a summary of the situation and post it to
> python annoucement as well.
Please don't. It's unlikely to do anything except incite a lot of
flames.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
Antoine Pitrou writes:
> Guido van Rossum python.org> writes:
> >
> > There are plenty of things we
> > can learn about fighting spam and other forms of vandalism from other
> > areas of the social web, including our very own wiki, and other wikis
> > (WikiPedia survives despite spam).
>
Brett Cannon writes:
> On Fri, Oct 9, 2009 at 11:32, Michael Foord wrote:
> > Sorry for top-posting, mobile device.
Michael, I for one *very much* appreciate your courtesy.
> Aahz was the most adamant hater of top-posting and he isn't subscribed to
> python-dev anymore, so whatever.
Please
Greg Ewing writes:
> That's no reason to squander it, though. Quoting the entire
> message every time makes the size of the thread grow as
> O(n**2),
Agreed, but let's not exaggerate. Threads are finite, so big O is not
really relevant. Spam OTOH is boundless, and that's where the
bandwidth
Ben Finney writes:
> "Stephen J. Turnbull" writes:
>
> > Trimming can be a PITA if you're using a crummy MUA
>
> How so? It merely requires the ability to navigate up and down by lines,
> and to select and delete text. I've used some very crumm
David Lyon writes:
> On Wed, 21 Oct 2009 18:38:26 -0700, Brett Cannon wrote:
> > David, you are making a huge leap here thinking that we even want
> > a package manager in the stdlib.
>
> Well - who is 'we'? If it's python-dev people I can accept and
> respect that.
Yes. The stdlib is a
Antoine Pitrou writes:
> Besides, the more keywords there are, the messier it is.
That's what I've found in the XEmacs tracker. Keywords are a
reasonable way (in the context of the Roundup implementation) to test
new classifications before going to the effort of messing with the
page templates.
Steven D'Aprano writes:
> I'm not being tongue-in-cheek or sarcastic. My question was serious --
> if there is a moratorium, is there any reason to bother submitting
> patches for functional changes to built-ins?
Yes. Python is open source. Private and public forks are possible
and (at lea
Ben Finney writes:
> Steven D'Aprano writes:
> > "get" is such a generic term that I don't believe that is a problem.
>
> The problem above is made less problematic by the fact that the function
> signature (e.g. 'foo_dict.get(key)') clarifies the answer to the
> question "get what?". Wher
"Martin v. Löwis" writes:
> > res.get() would be a fairly obvious way to do it. Enough that I would
> > probably never have gone searching for any of the other answers. Though
> > personally, I think I would call it "set.peek()", but the specific name
> > doesn't really matter to me.
>
> So
geremy condra writes:
> On Wed, Oct 28, 2009 at 12:34 PM, average wrote:
> > [I wrote:]
> >> If Python3 were to have this feature it would make it worth
> >> migrating to
> >
> > Sorry that may have sounded more harsh than I expected. If I had more
> > resources,
> This is effectively th
Steven D'Aprano writes:
> The usual technique people tend to come up with is:
>
> x = s.pop()
> s.add(x)
>
> Which strikes many people (including myself) as inelegant. Surely "get
> an element" is a more fundamental operation than "get an element and
> remove it"?
Not in a literal urn
Guido van Rossum writes:
> On Tue, Nov 3, 2009 at 11:23 AM, M.-A. Lemburg wrote:
> > One question:
> >
> > There are currently number of patch waiting on the tracker for
> > additional Unicode feature support and it's also likely that we'll
> > want to upgrade to a more recent Unicode versi
~b
<4222a8490911051521r1b9c8165id6e0f12d62da0...@mail.gmail.com>
<48c184130911051555r9a5b78cs3a13cb1345d3c...@mail.gmail.com>
<20091106001430.3229.796306500.divmod.xquotient@localhost.localdomain>
<4af3cf69.6090...@gmx.net>
<20091
anatoly techtonik writes:
> Does that mean even if authors of some imaginary editor agree to
> incorporate their code into Python, the framework that it is built
> upon will have to be incorporated into Python also (and eventually
> abandoned at original location)?
I would assume so. How els
Ben Finney writes:
> I would make a bug report for that, but the Python bug tracker also
> requires yet-another-identity. It's lunacy.
No, it's legacy. The software predates the availability of OpenID.
If you'd like to integrate Open ID authentication into Roundup, I will
personally be happy
David Lyon writes:
> I'm not star-gazing, because all these things are already
> needed and already being done to some degree in some
> organisations. There's already the libraries on pypi for
> most of this anyway.
Sure. But in a volunteer project, it's beg, buy, or build. Begging
has not
David Lyon writes:
> > I am just describing the needs and the end user PoV with the reference
> > implementation that happens to be used by *all* tools out there.
>
> That's good. That's what we need right now.
Martin's point is that the PEP process doesn't *have* "reference"
implementations
Ben Finney writes:
> Instead, the default should be `=='. That is, `Requires-Python: 3'
> should be equivalent to `Requires-Python: ==3'; and only "3" or "3.0" or
> "3.0.0" etc. will match. I maintain that is what most people will expect
> on seeing that syntax.
I really don't think your asse
david.l...@preisshare.net writes:
> >> Before we had : Requires-Python: 2.5, 2.6
> >>
> >> That made much more sense. It was simple and unambiguous, and is
> >> relevant to typical packaging scenarios.
> >
> > Unfortunately, it is fairly ambiguous, and makes no sense. It means
> > "requires
david.l...@preisshare.net writes:
> With respect, it's not a very common use case for a developer to
> say that package needs a python interpretor 'older' than 2.5.
Of course it is. I don't claim it is the majority of cases out there,
but stable versions of many of the packages I use will spec
Antoine Pitrou writes:
>
> > And in fact this case is often more the important one. Packages that
> > depend on having a *recent* version of python will often crash
> > quickly, before doing permanent damage, when an undefined syntax,
> > function, or method is invoked, while packages that d
Antoine Pitrou writes:
>
> > > How can they know that they depend on "a quirk in behaviour of an older
> > > version" if a newer version hasn't been released? This sounds bogus.
> >
> > Of course a newer version has been released. Who said it hasn't been?
> > Eg, the discussion of <=2.5.
Guido van Rossum writes:
> I'm a little hesitant about this. First of all, UTF-8 + BOM is crazy
> talk.
That doesn't stop many applications from doing it. Python should
perhaps not produce UTF-8 + BOM without a disclaimer of
indemnification against all resulting damage, signed in blood, from
t
Neil Schemenauer writes:
> On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote:
> > If people start taking the carrots we have added to 3.x and
> > backporting them to keep the 2.x series alive you are essentially
> > making the 3.x DOA by negating its benefits which I personally
> >
Barry Warsaw writes:
> (Besides, git in the stdlib doesn't make much sense :).
"Dulwich."
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-d
Michael Foord writes:
> This is why I'm keen that by *default* Python should honour the UTF8
> signature when reading files;
Unfortunately, your caveat about "a lot of the time it will *seem* to
work" applies to this as well. The only way that "honoring
signatures" really works is if Python
Michael Foord writes:
> When reading text files the presence of the UTF-8 signature *almost
> invariably* means a UTF-8 encoding. Honouring this will almost always be
> better than using the wrong encoding. Of course there are caveats, but
> it will be a substantial improvement.
Sure, that
Antoine Pitrou writes:
> Perhaps you are speaking with your emacs hat, where the purpose is
> to output to the same file that serves as input.
No, I'm not wearing my Emacs hat. If I was, there would be no
problem. You just use binary for most such purposes. Historically
that was how even Ema
Antoine Pitrou writes:
> Stephen J. Turnbull xemacs.org> writes:
> >
> > But it *does* determine the charset of ErrorDocuments displayed by
> > Apache. Users are likely to get somewhat confused if the
> > ErrorDocuments are in a different charset from your
"Martin v. Löwis" writes:
> My bet is that the majority of Python applications written today do
> "web" stuff. In the web, input encoding and output encoding are
> fairly decorrelated - in particular for databases and files read
> from disk.
Sure. Which means that programmers have to do a lo
Josiah Carlson writes:
> Lisp lists are really stacks
No, they're really (ie, concretely) singly-linked lists.
Now, stacks are an abstract data type, and singly-linked lists provide
an efficient implementation of stacks. But that's not what linked
lists "really are". For example, singly-lin
Josiah Carlson writes:
> On Thu, Jan 28, 2010 at 8:57 PM, Steve Howell wrote:
> > What do you think of LISP, and "car" in particular (apart from
> > the stupidly cryptic name)?
> Apples and oranges.
True, but speaking of Lisp lists, here's some possibly relevant
experience. About 10 years
Josiah Carlson writes:
> On Fri, Jan 29, 2010 at 11:31 PM, Stephen J. Turnbull
> wrote:
> > Some people complained, but we considered this well worthwhile (moving
> > one "type bit" from the car to the header allowed Lisp integers to
> > cover the
Minor erratum:
Stephen J. Turnbull writes:
> Emacs hasn't made that choice, XEmacs did. I believe Emacs is still
> "restricted" to 128MB, or maybe 256MB, buffers. They recently had an
> opportunity to increase integer size, and thus maximum buffer size,
> but
Antoine Pitrou writes:
> Yes, I hindsight I think Guido was right.
Guido does too. One of the benefits of having a time machine is
getting to turn your hindsight into foresight.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Antoine Pitrou writes:
> Besides, as Barry said, classifying a bug as blocker is also a good way
> to attract some attention on it. Other classifications, even "critical",
> don't have the same effect.
If done for the sole purpose of attracting attention, it's no
different from spam. Opinions
701 - 800 of 1495 matches
Mail list logo
