Quick questions:
Is mmap's inability to be subclassed a feature or bug?
Is one's inability to use a = mmapinstance.__setslice__;a(1,2,'a') (and
others) a feature or bug?
I would imagine they are bugs, but I just wanted to make sure and post
the report/request in the proper location.
Thank you,
Titus Brown [EMAIL PROTECTED] wrote:
- 1067760 -- float--long conversion on fileobj.seek calls, rather than
- float--int. Permits larger floats (2.0**62) to match large
- int (2**62) arguments. rhettinger marked as won't fix in
- the original bug report; this
because of that extra bit of
type checking. Otherwise I expect we'd see a more-mysterious
AttributeError or TypeError when the base method got around to
trying to do something with the bogus `self` passed to it.
[Josiah Carlson]
Agreed.
Well, it's not that easy to agree with. Guido replied
Nick Coghlan [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Since we already have the islice iterator, what's the point?
I'd like to see iterators become as easy to work with as lists are. At the
moment, anything that returns an iterator forces you to use the relatively
cumbersome
A.M. Kuchling [EMAIL PROTECTED] wrote:
On Tue, Feb 01, 2005 at 11:11:37AM -0500, Neal Becker wrote:
complex ('(2+2j)')
Traceback (most recent call last):
File stdin, line 1, in ?
ValueError: complex() arg is a malformed string
Whatever format is used for output should be
In a recent discussion in a SF patch, I noticed that PEP 328* only seems
to support relative imports within packages, while bare import
statements use the entirety of sys.path, not solving the shadowing of
standard library module names.
I have certainly forgotten bits of discussion from last
Guido van Rossum [EMAIL PROTECTED] wrote:
In a recent discussion in a SF patch, I noticed that PEP 328* only seems
to support relative imports within packages, while bare import
statements use the entirety of sys.path, not solving the shadowing of
standard library module names.
Hm. I'm
Guido van Rossum [EMAIL PROTECTED] wrote:
Sure. There are lots of FAQs whose answer is not Python will have to change.
And I'm not saying Python has to change either, hence the initial query
and planned PEP. Boiling it down; if we could change import in such a
way that made standard library
Guido van Rossum [EMAIL PROTECTED] wrote:
[Josiah Carlson]
if we could change import in such a
way that made standard library imports different from standard library
imports, we could
[Greg Ewing]
...go on to prove that black is white and get
ourselves killed by a python
Brian Sabbey [EMAIL PROTECTED] wrote:
I would like to get some feedback on a proposal to introduce
smalltalk/ruby-like code blocks to python. Code blocks are, among other
things, a clean way to solve the acquire/release problem [1][2]. This
proposal also touches on some of the problems
Brian Sabbey [EMAIL PROTECTED] wrote:
On Fri, 11 Mar 2005, Josiah Carlson wrote:
My first reaction to the proposal was ick. Why? Because every time
I've seen a mechanism for modifying the internals of generators
constructed using yield, the syntax has been awful; in my opinion
Brian Sabbey [EMAIL PROTECTED] wrote:
On Sat, 12 Mar 2005, Josiah Carlson wrote:
I stand by my clever hack statement, and I will agree to disagree with
you on it, like I agree to disagree with you about both the necessity of
passing arbitrary values back into a generator (I think
Greg Ewing [EMAIL PROTECTED] wrote:
Brian Sabbey wrote:
How about something like below? In the same way
that self is passed behind the scenes as the first argument, so can
the thunk be.
with stopwatch() result dt:
a()
b()
print 'it took', dt, 'seconds to compute'
Greg Ewing [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Since PEP 310 was already mentioned, can we just say that the discussion
can be boiled down to different ways of spelling __enter__/__exit__ from
PEP 310?
It's not quite the same thing. PEP 310 suggests a mechanism
Samuele Pedroni [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Greg Ewing [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Since PEP 310 was already mentioned, can we just say that the discussion
can be boiled down to different ways of spelling __enter__/__exit__ from
PEP 310?
It's
Jp Calderone [EMAIL PROTECTED] wrote:
On Thu, 17 Mar 2005 09:01:27 -0800, Josiah Carlson [EMAIL PROTECTED] wrote:
Nick Coghlan [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
[snip]
I think properties are the most used case where this kind of thing would
be nice
Paul Moore [EMAIL PROTECTED] wrote:
On Wed, 23 Mar 2005 10:33:53 -0600 (CST), Ka-Ping Yee
[EMAIL PROTECTED] wrote:
It dawned on me that you could use this idea to make the whole
filter/lambda experience vastly more pleasant. I whipped up a quick
implementation:
from
Ka-Ping Yee [EMAIL PROTECTED] wrote:
On Wed, 23 Mar 2005, Josiah Carlson wrote:
Paul Moore [EMAIL PROTECTED] wrote:
I thought about it, but couldn't convince myself that it would work
properly in all cases. I was thinking in terms of operator overloading
of everything possible - how
Jim Jewett [EMAIL PROTECTED] wrote:
Josiah Carlson:
I just noticed that decoration of classes was not included with the
@decoration syntax that made it into Python 2.4. ...
Is the fact that it didn't make it into 2.4 due to a pronouncement
Yes, but it wasn't a permanent decision
Michael Chermside [EMAIL PROTECTED] wrote:
Josiah Carlson writes:
[... stuff about reST and TeX ...]
While I have not used it often, I have done the equivalent of decorating
classes; it is as natural (though perhaps not quite as useful initially)
as decorating functions
Steve Holden [EMAIL PROTECTED] wrote:
[...]
Having to write
[x for x in seq]
to produce a copy of a list doesn't seem that outrageous to me, and I
don't find the predicate-less case of your proposal that convincing:
[x in seq]
seems somehow too terse.
And is already
Nicolas Fleury [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
import re2
buf='12 drummers drumming, 11 pipers piping, 10 lords a-leaping'
regex='^((?Pverse(?Pnumber\d+) (?Pactivity[^,]+))(, )?)*$'
pat2=re2.compile(regex)
x=pat2.extract(buf)
If one wanted to match the API of the re
[Guido van Rossum]
@EXPR:
CODE
would become something like
def __block():
CODE
EXPR(__block)
I'm not yet sure whether to love or hate it. :-)
Is it preferable for CODE to execute in its own namespace (the above
being a literal translation of the given code), or for it to
Guido van Rossum [EMAIL PROTECTED] wrote:
[Brett]
I think I agree with Samuele that it would be more pertinent to put all of
this
effort into trying to come up with some way to handle cleanup in a
generator.
I.e. PEP 325.
But (as I explained, and you agree) that still doesn't
[EMAIL PROTECTED] (holger krekel) wrote:
basically translates to:
if hasattr(x, '__enter__'):
x.__enter__()
try:
...
except:
if hasattr(x, '__except__'): x.__except__(...)
else: x.__exit__()
else:
x.__exit__()
Nope...
Toby Dickenson [EMAIL PROTECTED] wrote:
On Sunday 24 April 2005 07:42, Nick Coghlan wrote:
Shane Hathaway wrote:
While we're on the subject of block handler method names, do the method
names need four underscores? 'enter' and 'exit' look better than
'__enter__' and '__exit__'.
Jason Diamond [EMAIL PROTECTED] wrote:
Paul Svensson wrote:
You're not mentioning scopes of local variables, which seems to be
the issue where most of the previous proposals lose their balance
between hairy and pointless...
My syntax is just sugar for nested defs. I assumed the
Guido van Rossum [EMAIL PROTECTED] wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
Some highlights:
- temporarily sidestepping the syntax by proposing 'block' instead of 'with'
- __next__() argument simplified
Guido van Rossum [EMAIL PROTECTED] wrote:
Ouch. Another bug in the PEP. It was late. ;-)
The finally: should have been except StopIteration: I've updated
the PEP online.
Unless it is too early for me, I believe what you wanted is...
itr = iter(EXPR1)
arg = None
Guido van Rossum [EMAIL PROTECTED] wrote:
[Nicolas Fleury]
I would prefer something that would be
understandable for a newbie's eyes, even if it fits more with common
usage than with the real semantics behind it. For example a Boost-like
keyword like:
scoped EXPR as VAR:
Nick Coghlan [EMAIL PROTECTED] wrote:
Then, in Py3K, finalisation could simply become the default for loop
behaviour.
However, the '__finalise__' flag would result in some impressive code bloat,
as
any for loop would need to expand to:
itr = iter(EXPR1)
if getattr(itr,
arg = None
BLOCK1
if ex_block_2:
BLOCK2
Josiah Carlson wrote:
Indeed, I also mentioned this on Wednesday.
Though I was somewhat incorrect as code examples I offered express the
actual intent.
- Josiah
m.u.k [EMAIL PROTECTED] wrote:
Currently Py_FatalError only dumps the error to stderr and calls abort().
When doing quirky things with the interpreter, it's so annoying that process
just terminates. Are there any reason why we still dont have a simple
callback to hook Py_FatalError.
PS.
m.u.k [EMAIL PROTECTED] wrote:
Hi,
Guido van Rossum [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Your efforts would be better directed towards fixing the causes of the
fatal errors.
I see no need to hook Py_FatalError, but since it's open source, you
are of course free
m.u.k [EMAIL PROTECTED] wrote:
Josiah Carlson [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Offering any hook for Py_FatalError may not even be enough, as some of
those errors are caused by insufficient memory. What if a hook were
available, but it couldn't be called because
Edward C. Jones [EMAIL PROTECTED] wrote:
3. Add full tostring and fromstring capabilities for Python numeric
types. tostring(x) would return a string containing the binary
representation of x. For example, if x is a Python float, tostring(x)
would have eight characters. fromstring(s,
Josiah Carlson [EMAIL PROTECTED] wrote:
unsigned
vv
For 64 bit signed integers:
struct.pack(Q,...)
struct.unpack(Q,...)
My fingers were typing too fast (I do much work with unsigned 64 bit
integers, but not much with unsigned ones).
- Josiah
Ka-Ping Yee [EMAIL PROTECTED] wrote:
On Thu, 5 May 2005, Josiah Carlson wrote:
Ka-Ping Yee [EMAIL PROTECTED] wrote:
continue with 2
There is something about action which level that I just don't like.
Just to clarify: if by level you mean nesting level, did it appear
that the 2
Ron Adam [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
You should know why that can't work. If I pass a list, is a list an
iterator? No, but it should neither be created nor destroyed before or
after.
The discussion has been had in regards to why re-using 'for' is a
non
Ron Adam [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
I think a completely separate looping or non-looping construct would be
better for the finalization issue, and maybe can work with class's with
__exit__ as well as generators.
From what I understand, the entire conversation has
Ron Adam [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
It's not a matter of 'will they be finalized', but instead a matter of
'will they be finalized in a timely manner'. From what I understand;
upon garbage collection, any generator-based resource will be finalized
via __exit__/next
Eric Nieuwland [EMAIL PROTECTED] wrote:
I suggested to create AN ITERATOR FOR THE LIST and destroy that at the
end. The list itself remains untouched.
My mistake, I did not understand your use of pronouns.
- Josiah
___
Python-Dev mailing list
Ron Adam [EMAIL PROTECTED] wrote:
The argument over whether blocks should loop, I believe has been had;
they should. The various use cases involve multi-part transactions and
such.
I think so now too, I had thought as Nick does earlier this week that
the non-looping version was
Jim Jewett [EMAIL PROTECTED] wrote:
Nick Coghlan ncoghlan at gmail.com wrote:
Josiah Carlson wrote:
This has the benefit that an arbitrary block of code can be named,
and a named TerminateBlock used to exit it.
... I suspect any such implementation is going to need to use
Ron Adam [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Ron Adam [EMAIL PROTECTED] wrote:
There's also the possibility to use conditional looping based on the
value returned from the generator.
do VAR from EXPR if VAR==CONST:
BLOCK
This is a bit verbose
Shane Hathaway [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
That would be good, in my opinion. I updated PEP 3XX to use this idea:
http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
With that update (to version 1.6), PEP 3XX is basically PEP 343, but
injecting
exceptions
Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Monday 30 May 2005 17:06, Raymond Hettinger wrote:
There's no harm in having these surface. If the category is accurate,
let's use it. If the bug is out of date, we can mark it as such and
close it.
While we can't (and shouldn't)
Fernando Perez wrote:
Skip Montanaro wrote:
I wouldn't mind a stdlib that defined a set of top-level packages (some of
which might be wholly unpopulated by modules in the standard distribution)
It might, for example, define a gui package and gui.Tkinter and gui._tkinter
modules, leaving the
Fernando Perez wrote:
Josiah Carlson wrote:
Fernando Perez wrote:
I've wondered if it wouldn't be better if the std lib were all stuffed into
its own namespace:
from std import urllib
If a more structured approach is desired, it could be
from std.www import urllib
This generally brings up
Ron Adam wrote:
[snip]
Having less in the core distribution means smaller complete applications
to install when py2exe is used. There also needs to be some assurance
that the standard library has as few bugs in it as possible. The more
that's added to it, the more work and testing to do
Nick Coghlan [EMAIL PROTECTED] wrote:
Raymond Hettinger wrote:
More than case-statement semantics or PEP343, I wish for a dowhile
statement.
The most straight-forward way is to put the conditional expression at
the beginning of the block with the understanding that a dowhile keyword
Charles Cazabon [EMAIL PROTECTED] wrote:
Indeed. The original poster seems to want something that would work (not
necessarily look) like this:
do:
block
while condition
with block executed once prior to condition first being tested. But the
above is ugly, and you can get
Kay Schluehr [EMAIL PROTECTED] wrote:
Maybe anonymus function closures should be pushed forward right now not
only syntactically? Personally I could live with lambda or several
of the alternative syntaxes listed on the wiki page.
But asking for a favourite syntax I would skip the def
Kay Schluehr [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Kay Schluehr [EMAIL PROTECTED] wrote:
The arrow is a straightforward punctuation for function definitions.
Reusing existing keywords for different semantics seems to me as a kind
of inbreeding.
That's starting
Simon Wittber [EMAIL PROTECTED] wrote:
Why this discussion of yet another serialization format?
Pickle is stated to be unsafe. Marshal is also stated to be unsafe.
XML can be bloated, and XML+gzip is quite slow.
Do size,speed, and security features have to mutually exclusive? No,
that
Donovan Baarda [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Donovan Baarda wrote:
As I see it, a lambda is an anonymous function. An anonymous function is
a function without a name.
And here we see why I'm such a fan of the term 'deferred expression'
instead of 'anonymous
Keith Dart [EMAIL PROTECTED] wrote:
Therefore, I would like to ask here if anyone has already started
something like this? If not, I will go ahead and do it (if I have time).
If all you need to do is read or write C-like types to or from memory,
you should spend some time looking through the
Nick Coghlan wrote:
Guido van Rossum wrote:
But as long as we are describing the
present state we should call a spade a spade, etc.
I guess I take a syntactic view of the status quo, because, while
lambdas may be implemented as anonymous functions, the current syntax
doesn't let me
Nick Coghlan [EMAIL PROTECTED] wrote:
Jp Calderone wrote:
If you use vars(self).update(locals()), it even looks halfway
pleasant ;) I'm not sure what python-dev's current opinion of
vars(obj) is though (I'm hoping someone'll tell me).
Of course, both of these fall over for
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Now, don't get me wrong, definining __slots__ can be a pain in the
tookus, but with a proper metaclass, that metaclass can define the
__slots__ attribute based on the argument list for __init__().
There you go
Guido van Rossum [EMAIL PROTECTED] wrote:
On 7/7/05, François Pinard [EMAIL PROTECTED] wrote:
[Guido van Rossum]
I even wonder if else-clauses on for/while were a good idea.
I surely find them useful, and see them as a Python originality (a
welcome one).
They are indeed an
Andrew Durdin [EMAIL PROTECTED] wrote:
On 7/7/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I don't think so. It smells too much of DWIM, which is very unpythonic.
EIBTI.
In what way? The scheme described is explicit, and consistently
applied to all triple-quoted strings[*] --
Andrew Durdin [EMAIL PROTECTED] wrote:
On 7/11/05, Josiah Carlson [EMAIL PROTECTED] wrote:
You are wrong. Current string literals are explicit. They are what you
type.
No they are not:
Apparently my disclaimer of except in the case of the decades-old
string escapes that were
Brett Cannon [EMAIL PROTECTED] wrote:
On 7/30/05, Josiah Carlson [EMAIL PROTECTED] wrote:
Brett Cannon [EMAIL PROTECTED] wrote:
+-- Warning
+-- DeprecationWarning
+-- FutureWarning
+-- PendingDeprecationWarning
Don't like the idea of having
Your email is off-topic for python-dev, which is for the development OF
Python. Repost your question on python-list.
- Josiah
Joseh Martins [EMAIL PROTECTED] wrote:
Hello Everybody,
I´m a beginner in python dev..
Well, i need to implement a external ping command and get the results
For 2.5a1...
Some exposure of _PyLong_AsByteArray() and _PyLong_FromByteArray() to
Python. There was a discussion about this almost a year ago
(http://python.org/sf/1023290), and no mechanism (struct format code
addition, binascii.tolong/fromlong, long.tostring/fromstring, ...)
actually made it
Steven Bethard [EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
So I would propose the syntax
lst.sort(key=virtual.lower) # where virtual is functional.virtual
Shane Hathaway wrote:
class virtual:
def __getattr__(self, name):
return lambda obj: getattr(obj,
Steven Bethard [EMAIL PROTECTED] wrote:
I agree that an operator.methodcaller() shouldn't try to support
multiple methods. OTOH, the syntax
methodcall.method(*args, **kwargs)
doesn't really lend itself to multiple methods either.
But that's OK, we don't want to be calling multiple
Terry Reedy [EMAIL PROTECTED] wrote:
Josiah Carlson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Terry Reedy [EMAIL PROTECTED] wrote:
Can str.find be listed in PEP 3000 (under builtins) for removal?
Guido has already approved,
I noticed, but he approved before anyone
Steve Holden [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Donovan Baarda [EMAIL PROTECTED] wrote:
[...]
One thing that has gotten my underwear in a twist is that no one has
really offered up a transition mechanism from str.find working like now
and some future str.find or lack
Raymond Hettinger [EMAIL PROTECTED] wrote:
[Guido]
Another observation: despite the derogatory remarks about regular
expressions, they have one thing going for them: they provide a higher
level of abstraction for string parsing, which this is all about.
(They are higher level in that you
Raymond Hettinger [EMAIL PROTECTED] wrote:
As promised, here is a full set of real-world comparative code
transformations using str.partition(). The patch isn't intended to be
applied; rather, it is here to test/demonstrate whether the new
construct offers benefits under a variety of use
Tim Peters [EMAIL PROTECTED] wrote:
Anyone remember why setdefault's second argument is optional?
d = {}
d.setdefault(666)
d
{666: None}
For quick reference for other people, d.setdefault(key [, value])
returns the value that is currently there, or just assigned. The only
case
[EMAIL PROTECTED] wrote:
Substr didn't copy as partition() will have to, won't many of uses of
partition() end up being O(N^2)?
Yes. But if you look at most cases provided for in the standard library,
that isn't an issue. In the case where it becomes an issue, it is
generally because a user
Steve Holden [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 8/30/05, Andrew Durdin [EMAIL PROTECTED] wrote:
[confusion]
Hm. The example is poorly chosen because it's an end case. The
invariant for both is (I'd hope!)
.join(s.partition()) == s == .join(s.rpartition())
Steve Holden [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
the problem isn't the time it takes to unpack the return value, the problem
is that
it takes time to create the substrings that you don't need.
Indeed, and therefore the performance of rpartition is likely to get
worse as
Greg Ewing [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
A bit of free thought brings me to the (half-baked) idea that if string
methods accepted any object which conformed to the buffer interface;
mmap, buffer, array, ... instances could gain all of the really
convenient methods
[EMAIL PROTECTED] wrote:
I'm skeptical about performance as well, but not for that reason. A
string object can have a referent field. If not NULL, it refers to
another string object which is INCREFed in the usual way. At string
deallocation, if the referent is not NULL,
Raymond Hettinger [EMAIL PROTECTED] wrote:
[Jonny Reichwald]
I would like to suggest a small enhancement to str.strip().
By expanding its current form, where it only takes a char list, to
taking any list containing either char lists or string lists, it is
possible to remove entire
Guido van Rossum [EMAIL PROTECTED] wrote:
On 9/6/05, Greg Ewing [EMAIL PROTECTED] wrote:
A better plan would be to build something akin to
Pyrex into the scheme of things, so that all the
refcount/GC issues are taken care of automatically.
That sounds exciting. I have to admit that
Christopher Armstrong [EMAIL PROTECTED] wrote:
On 9/7/05, Josiah Carlson [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
On 9/6/05, Greg Ewing [EMAIL PROTECTED] wrote:
A better plan would be to build something akin to
Pyrex into the scheme of things, so that all
Fernando Perez [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Here's a perspective from the trenches as it were.
I've been writing quite a bit of code, initially all in Python (27k
lines in the last year or so). It worked reasonably well and fast. It
wasn't fast enough. I needed
Fredrik Lundh [EMAIL PROTECTED] wrote:
Karl Chen wrote:
Hi, has anybody considered adding something like this:
a = [1, 2]
[ 'x', *a, 'y']
as syntactic sugar for
a = [1, 2]
[ 'x' ] + a + [ 'y' ].
Notes:
- This is a common operation
is it?
Not in the
Gareth McCaughan [EMAIL PROTECTED] wrote:
The problems with syntax are
1 It adds cognitive load.
2 It makes your code look like line noise.
3 It reduces options for future development.
4 It complicates the parser.
I don't know about #4, but I suspect it (along with the related
Alexander Myodov [EMAIL PROTECTED] wrote:
Hello Josiah,
JC Alexander,
JC The essence of what you have proposed has been proposed (multiple times)
before,
JC and I seem to remember it was shot down.
To increase my understanding of Python-way, can you (or someone else)
explain the
Antoine Pitrou [EMAIL PROTECTED] wrote:
The best way to make people stop complaining about the GIL and start
using
process-based multiprogramming is to provide solid, standardized support
for process-based multiprogramming.
100% agreed. I needed a portable way to know if a
Bill Janssen [EMAIL PROTECTED] wrote:
The best way to make people stop complaining about the GIL and start
using
process-based multiprogramming is to provide solid, standardized support
for process-based multiprogramming.
And the model provided by the thread abstraction is a good
Alexander Myodov [EMAIL PROTECTED] wrote:
Hello,
Don't want to be importunate annoyingly asking the things probably
trivial for experienced community, but need to ask it anyway, after
spending about two hours trying to find well-camouflaged error caused
by it.
In the future you
Andrew Koenig [EMAIL PROTECTED] wrote:
My problem with this syntax is that it can be hard to read:
return if self.arg is None then default else self.arg
looks worryingly like
return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
to me.
Interesting. What about
Alexander Myodov [EMAIL PROTECTED] wrote:
[snip Alexander Myodov complaining about how Python works]
i = 0
while i != 1:
i += 1
j = 5
print j
Maybe you don't realize this, but C's while also 'leaks' internal
variables...
int i = 0, j;
while (i != 1) {
i++;
j = 5;
}
Alexander Myodov [EMAIL PROTECTED] wrote:
for (int i = 0; i 10; i++) works fine nowadays.
JC I'm sorry, but you are wrong. The C99 spec states that you must define
JC the type of i before using it in the loop. Maybe you are thinking of
JC C++, which allows such things.
gcc -std=c99
Gareth McCaughan [EMAIL PROTECTED] wrote:
[seems to have gone off list with a portion of the discussion]
The reason I like a if b else c is because it has the
most natural word order. In English,
My dog is happy if he has a bone, else sad.
sounds much more natural than
My dog is,
Micah Elliott [EMAIL PROTECTED] wrote:
Josiah an unofficial spec is sufficient. See koders.com and search
Josiah for 'fixme' to see some common variants.
But that's the problem -- there are already a bunch of unofficial
specs, which don't serve much purpose as such. It's a cool site. I
Antoine Pitrou [EMAIL PROTECTED] wrote:
Le lundi 03 octobre 2005 à 14:59 +0200, Fredrik Lundh a écrit :
Antoine Pitrou wrote:
A good rule of thumb is to convert to unicode everything that is
semantically textual
and isn't pure ASCII.
How can you be sure that something that
Michael Sparks [EMAIL PROTECTED] wrote:
What I'd be interested in, is hearing how our system doesn't match with
the goals of the hypothetical concurrency system you'd like to see (if it
doesn't). The main reason I'm interested in hearing this, is because the
goals you listed are ones we want
Michael Sparks [EMAIL PROTECTED] wrote:
On Thursday 06 October 2005 23:15, Josiah Carlson wrote:
[... 6 specific use cases ...]
If Kamaelia is able to handle all of the above mechanisms in both a
blocking and non-blocking fashion, then I would guess it has the basic
requirements
Adam Olsen [EMAIL PROTECTED] wrote:
I need to stress that *only* the new, immutable and thread-safe
mark-and-sweep types would be affected by these changes. Everything
else would continue to exist as it did before, and the benchmark
exists to show they can coexist without killing
Michael Sparks [EMAIL PROTECTED] wrote:
[ Possibly overlengthy reply. However given a multiple sets of cans of
worms... ]
On Friday 07 October 2005 07:25, Josiah Carlson wrote:
One thing I notice is absent from the Kamaelia page is benchmarks.
That's largely for one simple reason: we
Adam Olsen [EMAIL PROTECTED] wrote:
On 10/7/05, Josiah Carlson [EMAIL PROTECTED] wrote:
Adam Olsen [EMAIL PROTECTED] wrote:
I need to stress that *only* the new, immutable and thread-safe
mark-and-sweep types would be affected by these changes. Everything
else would continue to exist
Michael Sparks [EMAIL PROTECTED] wrote:
On Saturday 08 October 2005 04:05, Josiah Carlson wrote:
I'm just offering the above as example benchmarks (you certainly don't
need to do them to satisfy me, but I'll be doing those when my tuple
space implementation is closer to being done
1 - 100 of 478 matches
Mail list logo
