On 2005 Jan 15, at 01:02, Glyph Lefkowitz wrote:
...
Now, we have nowhere to hide PointPen's state on SegmentPen - and why
were we trying to in the first place? It's a horrible breach of
encapsulation. The whole *point* of adapters is to convert between
*different* interfaces, not merely to r
On 2005 Jan 15, at 02:30, Phillip J. Eby wrote:
is requested. It's too bad Python doesn't have some sort of
deallocation hook you could use to get notified when an object goes
away. Oh well.
For weakly referenceable objects, it does. Giving one to other objects
would be almost isomorphic to m
On 2005 Jan 16, at 03:17, Phillip J. Eby wrote:
...
Uh oh. I just used "view" to describe an iterator as a view on an
iterable, as distinct from an adapter that adapts a sequence so that
it's iterable. :)
I.e., using "view" in the MVC sense where a given Model might have
multiple independe
copy.py, as recently discussed starting from a post by /F, has two
kinds of misbehaviors since 2.3 (possibly 2.2, haven't checked), both
connected to instance/type/metatype confusion (where do special methods
come from? in classic classes and types, from the instance, which may
delegate to the
On 2005 Jan 16, at 10:27, Martin v. Löwis wrote:
Simon Percivall wrote:
What would happen if Exception were made a new-style class, enforce
inheritance from Exception for all new-style exceptions, and allow all
old-style exceptions as before.
string exceptions would break.
Couldn't we just specialc
On 2005 Jan 16, at 10:28, Martin v. Löwis wrote:
Phillip J. Eby wrote:
Couldn't we require new-style exceptions to inherit from Exception?
Since there are no new-style exceptions that work now, this can't
break existing code.
This would require to make Exception a new-style class, right?
Not nec
On 2005 Jan 16, at 11:17, Raymond Hettinger wrote:
[Alex]
So, as per discussion here, I have prepared a patch (to the
maintenance
branch of 2.3, to start with) which adds unit tests to highlight these
issues, and fixes them in copy.py. This patch should go in the
maintenance of 2.3 and 2.4, but in
On 2005 Jan 16, at 12:03, Fredrik Lundh wrote:
Alex Martelli wrote:
Problem: to write unit tests showing that the current copy.py
misbehaves with a classic extension
type, I need a classic extension type which defines __copy__ and
__deepcopy__ just like /F's
cElementTree does. So, I made o
On 2005 Jan 17, at 14:45, Anthony Baxter wrote:
...
both, but, of course, everybody's welcome to help!). Surely this
can't
be the first case in which a bug got triggered only by a certain
behavior in an extension type, but I couldn't find precedents. Ideas,
suggestions, ...?
Beats me - worst
On 2005 Jan 19, at 11:10, Bob Ippolito wrote:
Do you REALLY think this should be True?!
isinstance(foo, unicode) and foo != unicode(foo)
H -- why not? In the generic case, talking about some class B, it
certainly violates no programming principle known to me that
"isinstance(foo, B) and
On 2005 Jan 20, at 00:14, Fredrik Lundh wrote:
Stuart Bishop wrote:
I don't think it is possible for plpythonu to fix this by simply
translating the line endings, as
this would require significant knowledge of Python syntax to do
correctly (triple quoted strings
and character escaping I think).
o
On 2005 Jan 20, at 02:47, Skip Montanaro wrote:
Phillip> Actually, this is one of those rare cases where
optimization
Phillip> and clarity go hand in hand. Human brains just don't
handle
Phillip> nesting that well. It's easy to visualize two levels of
nested
Phillip> structure,
On 2005 Jan 21, at 14:02, Nick Coghlan wrote:
Phillip's monkey-typing PEP (and his goal of making it easy to write
well behaved adapters) got me wondering about the benefits of
providing an adaptation. Adapter class that could be used to reduce
the boiler plate required when developing new adapt
On 2005 Feb 05, at 07:43, Anthony Baxter wrote:
Ok, so here's the state of play: 2.3.5 is currently aimed for next
Tuesday,
but there's an outstanding issue - the new copy code appears to have
broken something, see www.python.org/sf/1114776 for the gory details.
I'm completely out of time this wee
On 2005 Feb 05, at 16:49, Jeremy Hylton wrote:
On Sat, 5 Feb 2005 02:31:26 -0500, Raymond Hettinger <[EMAIL PROTECTED]>
wrote:
[Anthony]
While this is undoubtedly a bug fix, I'm not sure that it should be
backported - it will break people's code that is "working" now
(albeit
in a faulty way). Wha
On 2005 Feb 06, at 08:34, Tim Peters wrote:
...
The easy fix: instead of cls.__mro__ use inspect.getmro which deals
with that specifically.
...
Since the original bug report came from Zopeland, chances are good
(although the report is too vague to be sure) that the problem
involves ExtensionC
On 2005 Feb 06, at 19:42, Raymond Hettinger wrote:
Modified Files:
Tag: release23-maint
test_copy.py
Log Message:
fix bug 1114776
Don't forget release24-maint.
Done -- but the maintenance branch of 2.4 has a problem right now: it
doesn't pass unit tests, specifically test_os (I check
On 2005 Feb 19, at 06:03, Nick Coghlan wrote:
This is something I've typed way too many times:
Py> class C():
File "", line 1
class C():
^
SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a
function with no arguments still requires parenthe
On 2005 Feb 20, at 04:35, Jack Diederich wrote:
I always use new style classes so I only have to remember one set of
behaviors.
I agree: that's reason #1 I recommend always using new-style whenever I
teach / tutor / mentor in Python nowadays.
"__metaclass__ = type" is warty, it has the "action a
On 2005 Feb 20, at 05:20, Raymond Hettinger wrote:
...
This sort of thing is easy to test for and easy to fix. The question
is
whether we care about updating this module anymore or is it a relic.
Also, is the use case one that we care about. AFAICT, this has never
come up before.
I did have s
On 2005 Feb 20, at 17:06, Guido van Rossum wrote:
[Alex]
I did have some issues w/UserString at a client's, but that was
connected to some code doing type-checking (and was fixed by injecting
basestring as a base of the client's subclass of UserString and
ensuring the type-checking always used isin
On 2005 Feb 21, at 04:42, Guido van Rossum wrote:
Oh, bah. That's not what basestring was for. I can't blame you or
your
client, but my *intention* was that basestring would *only* be the
base of the two *real* built-in string types (str and unicode).
I think all this just reinforces the notion th
On Mar 11, 2005, at 17:28, Guido van Rossum wrote:
PS in the blog responses, a problem with sum() was pointed out --
unless you use the second argument, it will only work for numbers. Now
Why is that a *problem*? It solves the "end case (if the sequence is
empty" which you mention for any() and a
On Mar 11, 2005, at 18:18, Raymond Hettinger wrote:
str.join() is still the best practice for string concatenation.
...except you actually need unicode.join if the strings are of that
kind. Fortunately, ''.join intrinsically compensates:
>>> x=[u'\u0fe0']*2
>>> ''.join(x)
u'\u0fe0\u0fe0'
*withou
On Mar 11, 2005, at 19:39, Raymond Hettinger wrote:
[Alex]
If you're considering revisions to sum's design, my suggestion would
be
to find a way to let the user tell sum to use a more accurate approach
when summing floats.
FWIW, when accuracy is an issue, I use:
sum(sorted(data, key=abs))
...and
On Mar 13, 2005, at 08:35, Robey Pointer wrote:
In other words, I don't think that the argument "users may have
written code to work around the bug" is a valid reason to not fix a
bug.
+1, as long as the bugfix doesn't break the workaround (and os.access's
bug seems to meet this criterion).
Ale
On Mar 14, 2005, at 01:22, Greg Ewing wrote:
Guido van Rossum wrote:
- the identity (defaulting to 0) if the sequence is empty
- the first and only element if the sequence only has one element
- (...(((A + B) + C) + D) + ...) if the sequence has more than one
element
While this might be reasonable
On Mar 14, 2005, at 10:57, Gareth McCaughan wrote:
of way as it's distracting in C or C++ seeing
Thing thing = new Thing();
with the type name appearing three times.
I think you can't possibly see this in C:-), you need a star there in
C++, and you need to avoid the 'new' (just cal
On Mar 14, 2005, at 11:20, Nick Coghlan wrote:
...
Somewhat ugly, but backwards compatible:
I realize you're mostly talking semantics, not implementation, but, as
long as we're at it, could we pretty please have back the optimization
indicated by...:
# Add the elements
if isinstance(valu
On Mar 15, 2005, at 01:16, Tim Peters wrote:
[Eric Nieuwland]
Perhaps the second argument should not be optional to emphasise this.
After all, there's much more to sum() than numbers.
[Greg Ewing]
I think practicality beats purity here. Using it on
numbers is surely an extremely common case.
I'd pe
On Mar 29, 2005, at 17:41, Terry Reedy wrote:
...
"Steve Holden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Having to write
[x for x in seq]
to produce a copy of a list doesn't seem that outrageous to me,
Except for (currently) leaving the last value of sequence bound to 'x'
On Apr 7, 2005, at 07:58, Raymond Hettinger wrote:
Does anyone know what has become of the following developers and
perhaps
have their current email addresses? Are any of these folks still
active
in Python development?
Ben Gertzfield
Charles G Waldman
Eric Price
Finn Bock
Ken Manheime
On Apr 10, 2005, at 13:44, Skip Montanaro wrote:
Michael> I suppose one could jsut do it unconditionally and wait
for one
Michael> of the three remaining VAX users[2] to compile Python 2.5
and
Michael> then notice.
You forgot the two remaining CRAY users. Since their machines are so
On Apr 19, 2005, at 15:57, BJörn Lindqvist wrote:
RSMotD (random stupid musing of the day): so I wonder if the decorator
syntax couldn't be extended for this kind of thing.
@acquire(myLock):
code
code
code
Would it be useful for anything other than mutex-locking? And wouldn't
Well, one
On Apr 22, 2005, at 16:51, holger krekel wrote:
Moreover, i think that there are more than the "transactional"
use cases mentioned in the PEP. For example, a handler
may want to log exceptions to some tracing utility
or it may want to swallow certain exceptions when
its block does IO operations th
On Apr 30, 2005, at 08:34, Raymond Hettinger wrote:
I haven't heard back from Greg Stein, Jim Fulton, or Paul Prescod.
If anyone can get in touch with them, that would be great.
I suspect that Jim may want to keep the commit privileges active
and that Paul and Greg are done with commits for the tim
On May 4, 2005, at 01:57, Paul Moore wrote:
> tried to construct a plausible example, I couldn't find a case which
> made real-life sense. For example, with Nicolas' original example:
>
> for name in filenames:
> opening(name) as f:
> if condition: break
>
> I can't think
On May 9, 2005, at 21:58, Guido van Rossum wrote:
> Apologies if this has been discovered and rejected already; I've had
> to skip most of the discussions but this though won't leave my head...
Skimming rather than skipping all of the discussion burned most of my
py-dev time, and it was just s
On 2/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
...
> I don't like to add a built-in index() at this point; mostly because
> of Occam's razor (we haven't found a need).
I thought you had agreed, back when I had said that __index__ should
also be made easily available to implementors of
On 2/14/06, Just van Rossum <[EMAIL PROTECTED]> wrote:
...
> Maybe it's even better to use opentext() AND openbinary(), and deprecate
> plain open(). We could even introduce them at the same time as bytes()
> (and leave the open() deprecation for 3.0).
What about shorter names, such as 'text' i
On Feb 15, 2006, at 9:51 AM, Barry Warsaw wrote:
> On Wed, 2006-02-15 at 09:17 -0800, Guido van Rossum wrote:
>
>> Regarding open vs. opentext, I'm still not sure. I don't want to
>> generalize from the openbytes precedent to openstr or openunicode
>> (especially since the former is wrong in 2.x
On 2/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> A bunch of Googlers were discussing the best way of doing the
...
Wow, what a great discussion! As you'll recall, I had also mentioned
the "callable factory" as a live possibility, and there seems to be a
strong sentiment in favor of tha
On 2/17/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Ian Bicking wrote:
>
> >> Unfortunately, a @property decorator is impossible...
> >
> > It already works! But only if you want a read-only property. Which is
> > actually about 50%+ of the properties I create. So the status quo is
> > not rea
On Feb 18, 2006, at 12:38 AM, Georg Brandl wrote:
> Guido van Rossum wrote:
>> WFM. Patch anyone?
>
> Done.
> http://python.org/sf/1434038
I reviewed the patch and added a comment on it, but since the point
may be controversial I had better air it here for discussion: in 2.4,
property(fset=
On Feb 20, 2006, at 5:41 AM, Guido van Rossum wrote:
...
> Alternative A: add a new method to the dict type with the semantics of
> __getattr__ from the last proposal, using default_factory if not None
> (except on_missing is inlined). This avoids the discussion about
> broken invariants, but o
On Feb 20, 2006, at 8:35 AM, Raymond Hettinger wrote:
> [GvR]
>> I'm not convinced by the argument
>> that __contains__ should always return True
>
> Me either. I cannot think of a more useless behavior or one more
> likely to have
> unexpected consequences. Besides, as Josiah pointed out, it
On Feb 20, 2006, at 12:33 PM, Guido van Rossum wrote:
...
> You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
> is perfectly fine there and hard to improve upon.
I see d[k]+=1 as a substantial improvement -- conceptually more
direct, "I've now seen one more k than I had
On Feb 20, 2006, at 12:38 PM, Aahz wrote:
...
>> Can you say, for the record (since nobody else seems to care), if
>> d.getorset(key, func) would work in your use cases?
>
> Because I haven't been reading this thread all that closely, you'll
> have
> to remind me what this means.
Roughly the
On Feb 20, 2006, at 3:04 PM, Brett Cannon wrote:
...
>> - "Yes and it should be the only constructor argument." This is my
...
> While #3 is my preferred solution as well, it does pose a Liskov
> violation if this is a direct dict subclass instead of storing a dict
How so? Liskov's pr
On Feb 20, 2006, at 5:05 PM, Raymond Hettinger wrote:
> [Alex]
>>> I see d[k]+=1 as a substantial improvement -- conceptually more
>>> direct, "I've now seen one more k than I had seen before".
>
> [Guido]
>> Yes, I now agree. This means that I'm withdrawing proposal A (new
>> method) and champio
On Feb 21, 2006, at 6:53 AM, Bengt Richter wrote:
> Perhaps a more informative message would be nice.
> Here's an easy way to trigger it:
>
compile("#-*- coding: ascii -*-\nprint 'ab%c'\n"%0x80, '','exec')
> Traceback (most recent call last):
>File "", line 1, in ?
> MemoryError
Defin
On Feb 21, 2006, at 1:51 AM, Greg Ewing wrote:
...
> Just one more thing -- have you made a final decision
> about the name yet? I'd still prefer something like
> 'autodict', because to me 'defaultdict' suggests
autodict is shorter and sharper and I prefer it, too: +1
> etc.) it seems more a
On Feb 22, 2006, at 7:21 AM, Raymond Hettinger wrote:
...
> I'm somewhat happy with the patch as it stands now. The only part
> that needs serious rethinking is putting on_missing() in regular
> dicts. See my other email on that subject.
What if we named it _on_missing? Hook methods int
mbers of Python:
>
> Guido van Rossum
> Alex Martelli
T-shirts? I'm an absolute fan of T-shirts...!-)
> The point is that I don't know some of you, so please grab my shoulder
> here in PyCon. And if you're not coming to the conference but somebody
>
On 2/24/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Michael Chermside wrote:
> >> The next() method of iterators was an interesting
> >> object lesson. ... Since it was sometimes invoked by name
> >> and sometimes by special mechanism, the choice was to use the
> >> unadorned name, but lat
On Feb 25, 2006, at 4:43 PM, [EMAIL PROTECTED] wrote:
> Zitat von Facundo Batista <[EMAIL PROTECTED]>:
>
>> The question is, it's ok to use a third party system for this
>> initiative? Or you (we) prefer to host it in-house? Someone alredy
>> thought of this?
>
> I thought about it at one time, a
On Feb 26, 2006, at 11:47 AM, Ron Adam wrote:
...
> How would you know you aren't in inadvertently masking a name in a
> function you call?
What does calling have to do with it? Nobody's proposing a move to
(shudder) dynamic scopes, we're talking of saner concepts such as
lexical scopes a
On Feb 26, 2006, at 4:20 PM, Ron Adam wrote:
...
> (sigh of relief) Ok, so the following example will still be true.
Yep, no danger of dynamic scoping, be certain of that.
> Maybe something explicit like:
>
import __main__ as glob
Sure, or the more general ''glob=__import__(__name__)''
On Feb 26, 2006, at 5:43 PM, Ron Adam wrote:
...
> So far everywhere I've seen closures used, a class would work. But
> maybe not as conveniently or as fast?
Yep. In this, closures are like generators: much more convenient
than purpose-built classes, but not as general.
> Haskel sounds in
On 2/27/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Microsoft has recently released their express version of the Visual C++.
> Given that this version is free for everyone, wouldn't it make sense
> to ship Python 2.5 compiled with this version ?!
>
> http://msdn.microsoft.com/vstudio/express
On Mar 6, 2006, at 4:43 PM, Bob Ippolito wrote:
>
> On Mar 6, 2006, at 4:14 PM, Guido van Rossum wrote:
...
>> I wonder if this use case and the frequently requested
>> case-insensitive dict don't have some kind of generalization in
>> common
>> -- perhaps a dict that takes a key function a
On Mar 6, 2006, at 10:17 AM, Tim Peters wrote:
...
> How's everyone doing, BTW?
Swimmingly, thanks! Too busy to breathe, or come to pycon:-(, but,
happy as a lark.
> I think I picked up the Texas Mystery
> Disease from Holger Krekel -- bed-ridden 20 hours Saturday, and most
> of Sunday, w
On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
...
> I think that adding parentheses would help, by at least signalling
> that the logic is longer than just the next (single) expression.
>
> level = (0 if "absolute_import" in self.futures else -1)
+1 (just because I can't give it +3.1415
On Mar 7, 2006, at 6:15 AM, Georg Brandl wrote:
> Hi,
>
> while "as" is being made a keyword, I remembered parallels between
> "with"
> and a proposal made some time ago:
>
> with expr as f:
> do something with f
>
> while expr as f:
> do something with f
>
> if expr as f:
> do some
On Mar 7, 2006, at 7:29 AM, Steve Holden wrote:
...
>> In fact, I think the below examples are reasonable uses
>> that do a better job of expressing intent than the if
>> statement would. I just don't like the mental backtrack
>> they require, and would like some sort of advance
>> warning.
On Mar 12, 2006, at 11:16 AM, Ian Bicking wrote:
...
> memoize seems to fit into functools fairly well, though deprecated not
> so much. functools is similarly named to itertools, another module
> that
> is kind of vague in scope (though functools is much more vague).
> partial would make j
On Mar 13, 2006, at 12:29 PM, Fabiano Sidler wrote:
> Hi folks!
Hello Fabiano! The proper venue for your interesting issues is
comp.lang.python (or the equivalent mailing list), where all sorts of
people will be able to "hear" you, discuss things, and help out.
python-dev is strictly for
On Mar 13, 2006, at 7:22 PM, A.M. Kuchling wrote:
...
> Design Patterns in Python (3)
> Anything Alex Martelli wants to talk about.(3)
...
> Language howtos (I really enjoyed Alex Martelli's talk last year on
> itertools) (1)
Wow, I'm blushing;-). I promise
On Mar 16, 2006, at 7:30 PM, Brett Cannon wrote:
...
> I agree. "as" is taking on the use of assignment in statements that
> are not ``=`` and I say we just keep on with that. Plus Greg's above
Hmmm, if we allowed '( as )' for generic expr's we'd make
a lot of people pining for 'assignmen
Can't think of a more Pythonic way to celebrate St Patrick's day!-)
Alex
___
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
On Mar 19, 2006, at 7:42 PM, Guido van Rossum wrote:
...
>> There seem to be other places where Python is beginning to require
>> parens
>> even though they aren't strictly necessary to resolve syntactic
>> ambiguity.
>
> In the style guide only, I hope. The parens that are mandatory in a
On Mar 25, 2006, at 9:57 PM, Aahz wrote:
> I'd really like to see someone else who understands the issues (i.e.
> using the Python C-API) weigh in. Both Barry and Raymond are clever
> programmers who generally understand what's Pythonic, and I find
> myself
> agreeing with whoever posted last.
On Mar 26, 2006, at 8:43 AM, Raymond Hettinger wrote:
> [Aahz]
>> Speaking as a person who does relatively little C programming, I
>> don't
>> see much difference between them. The first example is more
>> Pythonic --
>> for Python. I agree with Barry that it's not much of a virtue for C
>>
On 3/29/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 3/29/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
> > from a user perspective, adding this to the standard library is a
> > no-brainer.
> > the only reason not to add it would be if the release managers don't have
> > time to sort out the bu
On Mar 27, 2006, at 7:20 AM, Raymond Hettinger wrote:
> Why don't we expose _PySet_Next() for Barry and leave it out of the
> public API
> for everyone else.
There are precedents for adding some functionality to the C API but
not documenting it to ensure "non advanced users" don't get hurt -
It's a bit late for 2.5, of course, but, I thought I'd propose it
anyway -- I noticed it on c.l.py.
In 2.3/2.4 we have many ways to generate and process iterators but
few "accumulators" -- functions that accept an iterable and produce
some kind of "summary result" from it. sum, min, max, fo
On Apr 4, 2006, at 8:01 AM, Jeremy Hylton wrote:
> On 4/4/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>> import collections
>> def tally(seq):
>> d = collections.defaultdict(int)
>> for item in seq:
>> d[item] += 1
>> ret
On 4/4/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Alex]
> > This is quite general and simple at the same time: for example, it
> > was proposed originally to answer some complaint about any and all
> > giving no indication of the count of true/false items:
> >
> > tally(bool(x) for x in se
On Apr 4, 2006, at 8:18 PM, Crutcher Dunnavant wrote:
...
>> There's no rule that predicate cannot raise an exception.
>
> No, but it makes many applications (such as using it as a test in list
> comprehensions) difficult enough to not be worth it.
IMHO, the solution to THAT very real problem
On Apr 4, 2006, at 10:53 PM, Jess Austin wrote:
> Alex wrote:
>> import collections
>> def tally(seq):
>> d = collections.defaultdict(int)
>> for item in seq:
>> d[item] += 1
>> return dict(d)
>
> I'll stop lurking and submit the following:
>
> def tally(seq):
> return
On Apr 5, 2006, at 8:30 PM, Greg Ewing wrote:
> A while ago there was some discussion about including
> elementtree in the std lib. I can't remember what the
> conclusion about that was, but if it does go ahead,
> I'd like to suggest that it be reorganised a bit.
>
> I've just started playing wit
On 4/6/06, Martin Blais <[EMAIL PROTECTED]> wrote:
...
> So I had the following idea: would it not be nice if there existed a
> string-prefix 'i' -- a string prefix like for the raw (r'...') and
> unicode (u'...') strings -- that would mark the string as being for
> i18n? Something like this (
Back from vacation, just did an svn up and make, and...:
...
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes Parser/acceler.o
Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o
Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/
firstsets.o Parser/grammar.o Parser
On Apr 21, 2006, at 7:46 AM, Aahz wrote:
> On Fri, Apr 21, 2006, Mateusz Rukowicz wrote:
>>
>> Next thing I would add is multi precision floating point type to
>> the core and fraction type, which in some cases highly improves
>> operations, which would have to be done using floating point instea
On 4/21/06, Mateusz Rukowicz <[EMAIL PROTECTED]> wrote:
...
> So I think the most valuable of my ideas would be improving long int +
> coding decimal in C. Anyway, I think it would be possible to add other
> ideas later.
I see "redo Decimal in C" (possibly with the addition of some fast
element
On 4/21/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
...
> > GMP is covered by LGPL, so must any such derivative work
>
> But the wrapper is just using GMP as a library, so
> it shouldn't be infected with LGPLness, should it?
If a lawyer for the PSF can confidently assert that gmpy is not a
deriva
gt;> build Python with free tools :-(
> [...]
>
> Actually, it's apparently still there, just at a different URL.
> Somebody posted the new URL on c.l.py a day or two back (Alex
> Martelli started the thread, IIRC). I'm off to the dentist, no
> time to Google fo
On Apr 24, 2006, at 12:19 AM, Martin v. Löwis wrote:
> Martin v. Löwis wrote:
>> - Paul Moore has contributed a Python build procedure for the
>> free version of the 2003 compiler. This one is without IDE,
>> but still, it should allow people without a VS 2003 license
>> to work on Python i
On Apr 24, 2006, at 12:48 AM, Neil Hodgson wrote:
> Martin v. Löwis:
>
>> Apparently, the status of this changed right now: it seems that
>> the 2003 compiler is not available anymore; the page now says
>> that it was replaced with the 2005 compiler.
>>
>> Should we reconsider?
>
>I expect Mi
On Apr 24, 2006, at 1:24 AM, Paul Moore wrote:
> On 4/24/06, Neil Hodgson <[EMAIL PROTECTED]> wrote:
>> Martin v. Löwis:
>>
>>> Apparently, the status of this changed right now: it seems that
>>> the 2003 compiler is not available anymore; the page now says
>>> that it was replaced with the 2005
On May 26, 2006, at 6:27 PM, Steve Holden wrote:
> Greg Ewing wrote:
>> Fredrik Lundh wrote:
>>
>>
>>> roughly speaking, epoll is kqueue for linux.
>>
>>
>> There are many different select-like things around now
>> (select, poll, epoll, kqueue -- are there others?) and
>> random combinations of t
On 6/9/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
...
> The language doesn't have zero-dimensional arrays, although it doesn't
> prevent users from defining them. but why would one want to index a
> zero-dimensional array, since it has no dimensions? It should be
> written as x, not x[].
W
On Jun 9, 2006, at 4:55 PM, Greg Ewing wrote:
...
> Think about how you get from an N dimensional array to
> an N-1 dimensional array: you index it, e.g.
>
> A2 = [[1, 2], [3, 4]] # a 2D array
>
> A1 = A2[1] # a 1D array
>
> A0 = A1[1] # a 0D array???
>
> print A0
>
> What do you think
...claims:
Note that for even rather small len(x), the total number of
permutations of x is larger than the period of most random number
generators; this implies that "most" permutations of a long
sequence can never be generated.
Now -- why would the behavior of "most" random number generators be
On Jun 10, 2006, at 1:08 PM, Josiah Carlson wrote:
> Josiah Carlson <[EMAIL PROTECTED]> wrote:
>>
>> Alex Martelli <[EMAIL PROTECTED]> wrote:
>>>
>>> ...claims:
>>>
>>> Note that for even rather small len(x), the total number of
On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
...
> (1) An expression of the form 'static' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition. If there is no surrounding function definition,
> 'static' is a no-op and the expres
What about doing it with a per-thread-timeout in TLS (overriding the
global one if a thread does have it set in its TLS)? Not as clean,
but perhaps far easier to implement than patching dozens of
modules/functions/classes to provide timeout= options everywhere...
Alex
On 7/5/06, Guido van Ross
In Italian that would be DBAV (Dittatore benevolo a vita)...;-)
Alex
On 7/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Frank> That said, I still regard Samuele Pedroni as the ultimate
> Frank> authority on Jython and give him pretty much full veto power. He
> Frank> fortu
On 11/4/05, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> I have a few claims, some unrelated, and some built on top of each
> other. I would like to hear your responses as to which are
> convincing, which arne't, and why. I think that if these claims are
> true, Python 3000 should change quite a bit.
>
On Nov 17, 2005, at 12:46 PM, Brett Cannon wrote:
...
>> alloca?
>>
>> (duck)
>>
>
> But how widespread is its support (e.g., does Windows have it)?
Yep, spelled with a leading underscore:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
vclib/html/_crt__alloca.asp
Alex
_
101 - 200 of 234 matches
Mail list logo
