compared to the built-in cmp
operation, it usually outweighed the algorithmic time considerations.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
;s a lot of people
licking their chops because it's sponsored by Google and everything
Google touches turns to gold, but that's just nameless plebians. I
trust the developers not to be easily convinced. If GvR allows this
into CPython without something like a typical 4x speed increase I&
On Jan 28, 8:10 am, a...@pythoncraft.com (Aahz) wrote:
> In article ,
> Neil Hodgson wrote:
>
> >Carl Banks:
>
> >> There is also no hope someone will fork Python 2.x and continue it in
> >> perpetuity. Well, someone might try to fork it, but they
#x27;t have any say in
> this.
Doesn't PSF own the Python trademark? Then it has to have a say, not
over whether someone can fork the project or make another official
release, but over whether they can do so and still call it Python.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
27;t stray very far from
Perl's core principles. Problem is, Perl wasn't ever a good language
so they won't succeed. IOW, as Geremy Condra said, "it's too much
like Perl".
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ust too much. I didn't like the suggestion that I should be
forced to put up with dozens of subdirectories, now you want me to
force me to put the source files into the subdirectories as well?
That would be a deal-breaker. Thankfully it is too ridiculous to ever
happen.
> Summary: I like
server pattern
(you'd have to create list- and dict-like types that know when
something is referencing them, and that notify the references whenever
they change).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
lassname);
inst = PyObject_CallFunctionObjArgs(cls,NULL);
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ot;.
>
> > The double underscores and name mangling are a red herring:
>
> I beg to disagree. The problem (well... what I think is a problem,
> actually) IS that name mangling is applied to a method *local* variable.
It's not (__a is a global), and I'll opine that the behavior is more
consistent and more easily explained the way it is. Consider the
following:
import foo
class uno(object):
def __init__(self):
__bar = 1
foo.__bar = 1
Now you have to explain why __bar would be name-mangled when set in
the foo module, but not when set in the current module.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
called (cdef __dealloc__ in Cython).
CObjects can be passed a C function as a deallocator; this should work
as reliably as a custom class deallocator.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
n else is used on a
for block with no break inside. I don't think the else can be invoked
in any other way. As a bonus it could catch some cases where people
mistakenly use it thinking it will execute when there are no
iterations.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Sep 29, 10:38 am, Duncan Booth
wrote:
> Carl Banks wrote:
> > Hmm, I wonder if Python should emit a warning if an else is used on a
> > for block with no break inside. I don't think the else can be invoked
> > in any other way. As a bonus it could cat
just kind of throwing the idea out there, wasn't really
advocating it.
Now that I am no longer confused I definitely don't think there should
be a warning.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
om type (one
that implements one of the pickling methods) for that. Or arrange for
whatever object contains the CObject to pack and unpack it manually.
Out of curiosity, what kind of data you storing in this CObject?
Maybe we can help you choose a better way to handle it at the C level.
Carl Banks
On Sep 29, 11:16 am, sturlamolden wrote:
> On 29 Sep, 19:11, Carl Banks wrote:
>
> > CObjects can be passed a C function as a deallocator; this should work
> > as reliably as a custom class deallocator.
>
> Except that __del__ prevents cyclic GC.
You are mistaken on two
hink
2.6+) can use mmap, too, now that it supports an offset parameter.
I don't think you can do that in Windows, though. I think you'd have
to use special system calls (via ctypes, for example).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ss.
Class instances, almost by default, maintain state, so naming a class
"state" says almost nothing about what the class is. Something like
GameState or PlayerState would be better.
Here is some reading material that can help you adjust your coding
style to help avoid such errors in the future:
http://www.python.org/dev/peps/pep-0008
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
#x27;t you think you should learn a bit more about how Python manages
objects and namespaces before going around calling things bugs?
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 3, 11:14 pm, horos11 wrote:
> Carl,
>
> Thanks for the info, but a couple of points:
>
> 1. it wasn't meant to be production code, simply a way to teach
> python.
I understand, and if you think it's overkill for your pedagogical
application then feel free n
On Oct 3, 11:45 pm, horos11 wrote:
> > It's not a bug. In Python classes and global variables share the same
> > namespace.
>
> > Don't you think you should learn a bit more about how Python manages
> > objects and namespaces before going around calling th
taxError. Because of Python's dynamicism the
compiler knows hardly anything about the objects at compile-time
(except in a few cases involving constants, which Python takes
advantage of to do some compile-time constant folding).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
; work.
In fairness, a lot of types define a to_string() method (especially
third-party types like numpy), but it's usually to produce a raw
binary output.
Presumably in Python 3 these methods will be renamed to_bytes.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Max or Blender? What is your mathematical background (especially in
linear algrebra)? Please help us help you by providing us details on
what you know already and what you want to do. You won't get much
help by asking simple yes/no questions.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
re.search(r'(.*?C1(?!.*C1))','C1b1b1b1 b3b3b3b3
>
> C1C2C3C4').groups()
> ('C1b1b1b1 b3b3b3b3 C1',)
>
> with the same problem.
>
> How could this be done?
Can't be done with regexps.
How you would do this kind of depends on your overall goals, but your
first look should be toward the string methods. If you share details
with us we can help you choose a better strategy.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 4, 11:17 pm, Wolfgang Rohdewald wrote:
> On Monday 05 October 2009, Carl Banks wrote:
>
> > What you're not realizing is that if a regexp search comes to a
> > dead end, it won't simply return "no match". Instead it'll throw
> > away
On Oct 5, 9:09 am, Manowar wrote:
> On Oct 4, 8:38 pm, Carl Banks wrote:
>
>
>
>
>
> > On Oct 4, 5:16 pm, Manowar wrote:
>
> > > On Oct 4, 6:38 pm, TerryP wrote:
>
> > > > On Oct 4, 10:05 pm, Manowar wrote:
>
> > > >
: ONE script. When you design it
that a file can be used either as a script or as a module, you are
asking for trouble.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ect sql if the alternative is some
hellspawn PHP ORM.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ame one from the first object.
>
> So, as we put it, once per class and not object.
>
> Saves on both time and space.
Sounds like Borg Pattern:
http://code.activestate.com/recipes/66531/
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 5, 11:07 pm, Carl Banks wrote:
> On Oct 5, 7:56 pm, menomnon wrote:
> > Does python have a ‘once’ (per class) feature?
>
> > ‘Once’, as I’ve know it is in Eiffel. May be in Java don’t.
>
> > The first time you instantiate a given class into an object it
> &
jects. Also you might want to clean up the module's namespace.
I del objects for these reasons sparingly, usually only when the
object uses a whole lot of memory, or the namespace is very messy.
However, I'm guessing that the person who wrote your code is just
overly paranoid.
hat
uses a single script as an entry point and inputs modules. But I'm
not going to tell an expert how to do it.
Average programmers, yes I will. Too easy to mess up, too hard to
understand, and too little benefit, so don't do it. File should be
either a module or script, not both.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
if not x.startswith('_'))
del _internals, _allnames
# del ok here because this does free memory
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ns are
>
> > emacs has the same efficiency on a terminal.
> > or maybe I don't understand your sentence.
>
> Perhaps this is a reference to the alt/meta/control/buckey/super
> key-chords that emacs is infamous for using
It's Esc-Meta-Alt-Ctrl-Shift
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
> 2.6.4 final is planned for 18-October.
>
> > Cheers,
> > -Barry
>
> > PGP.sig
> > < 1KViewDownload
>
> So I take it builds based on 2.6.3 should be avoided?
2.6.3 breaks setuptools:
http://bugs.python.org/issue7064
I might upgrade to 2.6.3 just for that benefit alone.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ax coloring.
Bright red comments definitely helps them stand out (the easier to
ignore them with), and cool blue strings provide a subtle syntax clue
while not being too distracting. Rest of the text is black.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ll further recommendation
> code disponible montao.googlecode.com- Hide quoted text -
When you do this:
import datetime
you have to do this
d = datetime.datetime()
And when you do this:
from datetime import datetime
you have to do this:
d = datetime()
You evidently did this:
from datetime import datetime
then this:
d = datetime.datetime()
which is not allowed.
If you want to self-comply, I recommend always doing it the first way.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
urce file "self.Edit.Filename" has changed.
>
> Could someone give me an explanation, why this happens ?
I'm guessing you have references to objects from the first time you
ran execfile that don't get updated. It's kind of hard to tell.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
"thread".
As far as I can discern doing that way (as opposed to using a Runnable
object) didn't have any effect except to make the logic harder to
understand.
So (getting back to Python) count me among those who say one usally
want to specify a target function instead of subclassing
threading.Thread.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
x27;)
mod = __import__(modname)
for pkgname in modpath[1:]:
mod = getattr(mod,pkgname)
mod.main() # or main(*sys.argv[2:]), or however you call it
5. Tell your users to stop entering commands like this:
$ ./python/mammal/otter.py
And start entering commands like this:
$ sa mammal.otter
With a little care this method will work fine, and will be installable
with cp -r.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
STRONGLY recommend against your
> decorator. You MUST NOT start threads a a side effect of a module
> import.
His decorator doesn't do that (necesarily).
His example code did that, but I took it to be an example script, and
it's kind of hard to run code that's not a side eff
On Oct 10, 2:26 am, niklasr wrote:
> On Oct 8, 10:17 pm, Carl Banks wrote:
>
>
>
> > On Oct 8, 3:11 pm, niklasr wrote:
>
> > > On Oct 8, 5:25 pm, "Diez B. Roggisch" wrote:
>
> > > > NiklasRTZ schrieb:
>
> > > &
in fact the slight visual
distinctness of it probably helps readability. Some people do get
finicky about columns and try to line things up all the time. It's
frustrating, wasteful, and ultimately hopeless, and sometimes
deceptive (lining things up can suggest relationships where none
ex
On Oct 11, 4:12 pm, Mensanator wrote:
> On Oct 11, 5:05 pm, Carl Banks wrote:
>
>
>
>
>
> > On Oct 11, 7:10 am, Grant Edwards wrote:
>
> > > On 2009-10-11, metal wrote:
>
> > > > I wonder the reason for ELIF. it's not aligned with IF, mak
u that it's not a simple issue to fix, it would be
involve spectacular and highly backwards-incompatible changes.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
No.
However, one thing that might work in your case would be to then pass
a dictionary as keyword arguments into a function that defines the
locals you need.
u['value'] = 1
u['sort'] = 2
u['key'] = 3
def something(value,sort,key):
return value + sort + key # look they're locals now
something(**u)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
7;re going to have a thread like this where no one
makes this mistake. Don't know when, but one day it will happen.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 13, 12:23 pm, Mick Krippendorf wrote:
> Carl Banks schrieb:
>
> > Lemme guess.
>
> > You tried this at the interactive prompt and concluded it worked in
> > general, right?
>
> Yes. Thank you for enlighten me.
>
> > One of these days we'r
on
chose to be like C instead of Fortran or Ada. I've used both kinds of
languages, and I prefer to have an external clue about the nature of
the object I'm dealing with. However, I use many languages that don't
distinguish between the two and it is not that big of a deal, and does
have some small advantages.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
h has a similar but not compatible api) you can do
it like this:
p=optparse.ArgumentParser()
p.add_argument("--debug",nargs='?')
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
especially bad cases, this has got to be one of the
top candidates.
Potentially grave inefficiency (order of magnitude loss of
performance), and very likely to be misused.
Carl Banks
(Course I think the right solution would have been a separate
concatenation operator, beyond hope now, though.)
--
ht
will call __str__,
whereas sum would call __add__, leading to potentially different
results. Therefore, transparently substituting a call to "".join is
not an option.
It'd be better to just remove the special case.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
think.
In future complaints about the language, you'll cut down on
techicalities if you respect the usage of the word "bug" and use a
term such as "intentional misfeature" instead.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
s absolutely ludicrous.
There's no justification for it.
Use islice(), or slice the iterable beforehand. Leave it out of
iterators.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ut the word
islice?
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
e extra overhead of homemade solution. You're
not. We get it.
If you want to do something about it, write a patch with some test
cases and submit it.
If you want to do something half-assed about it, submit hash= key as a
wishlist item.
If you want to do absolutely nothing about it, continue to
On Oct 15, 6:57 pm, Ishwor Gurung wrote:
> Too bad groupby is only available in Python2.6+
> Since you're here, any chance of getting your NDK team to look into
> getting some small subset of STL, Boost into Android?
Aren't Java collections bad enough? :)
On Oct 17, 2:15 am, Tim Chase wrote:
> Carl Banks wrote:
> > On Oct 16, 12:40 pm, Tim Chase wrote:
> >> Then I'm fine with sum() being smart enough to recognize this
> >> horrid case and do the "right" thing by returning ''.join()
> &
here is, by shutting out strings from sum,
you don't really lose much in terms of duck typing, because duck
typing wouldn't have been that helpful anyway.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 17, 2:22 pm, Alan G Isaac wrote:
> On 10/17/2009 7:06 AM, Carl Banks wrote:
>
> > I'm basically saying here is, by shutting out strings from sum,
> > you don't really lose much in terms of duck typing, because duck
> > typing wouldn't have been that
On Oct 18, 2:53 pm, Eloff wrote:
> On Oct 16, 7:38 pm, Carl Banks wrote:
>
> > You would burden everyone who writes a custom iterator to provide a
> > __getitem__ method just because you're too lazy to type out the word
> > islice?
>
> No, of course not. Tha
ue.
Consider this thought experiment:
class Something(object):
def __radd__(self,other):
return other + "q"
x = ["a","b","c",Something()]
If x were passed to "".join(), it would throw an exception; but if
passed to a sum() without any special casing, it would successfully
return "abcq".
Thus there is divergence in the two behaviors, thus transparently
calling "".join() to perform the summation is a Bad Thing Indeed, a
much worse special-case behavior than throwing an exception.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 19, 3:24 am, Tim Chase wrote:
> Carl Banks wrote:
> > Consider this thought experiment:
>
> > class Something(object):
> > def __radd__(self,other):
> > return other + "q"
>
> > x = ["a","b","c",Som
ther keeping references to old data
around (what I like to call a memory clog, as opposed to a memory
leak), or is allocating memory in such a way that it can't unwind the
heap and reclaim memory from a large array that was freed. The latter
seems unlikely to me, because any large memor
nstead of m.seek(addr &
MAP_MASK)
Another possibility is that the mmap object is accessing the memory
with bad alignment (when I see bus error the first thing I think of is
that a word was read from a non-word-aligned address). You don't
happen to be running this on a Power PC? What happens when you try
accessing the mmap data like an regular array?
All speculation, but my gut feeling is bug in mmap module.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
a good thing for something that exists so that it can be put on a
mobile device.
Still, I see PySide being the eventual end of my GUI toolkit journeys.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
e-by-byte access. (It's probably using a function such as
PyString_FromStringAndLen under the convers.)
I'm not sure you can even access the the memory through the mmap
object except byte-by-byte.
One way to get word access would be to use buffer protocol, which mmap
supports, and create
can make s.split(sep) behave like s.split(). That's not
unheard of but it does go against our typical expectations. It would
have been a better library design if s.split() and s.split(sep) were
different methods.
That they are the same method isn't the end of the world but the
documen
ject):
def __new__(cls,*args,**kwargs):
return object.__new__(cls)
def __init__(self,*args,**kwargs):
print args, kwargs
X(1,2,q=3,g=4)
Note that *args and **kwargs are not passed to object.__new__, but
nevertheless __init__ is still called with them.
What's actually happens is that the type object's __call__ method
passes the same arguments to both __new__ and __init__.
The fact is, object.__new__ does nothing at all with the args and
kwargs arguments, it just ignores them. So, when calling
object.__new__, don't pass them to it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 25, 9:04 pm, rh0dium wrote:
> On Oct 22, 9:05 pm, Carl Banks wrote:
> > This should suffice for you:
>
> > class Borg(object):
> > __shared_state = {}
> > def __init__(self, noSend=False,reportLevel=30,
> > reportMethods="B
Python 3 using 2to3,
you first have to port it to this transitional dialect.
If Unicode is the issue, one thing you should do to explicitly
classify all strings as binary or text in Python 2.x. This means to
change str() to unicode() or bytes(), whichever is appropriate, and to
change &quo
e.
Unix doesn't automatically search the current dir, doesn't use the
executable search path (libraries have their own search path, which is
not used when loading shared libs by hand), and system libraries on
Unix conventionally are prefixed by lib. So name collisions are rare,
but eve
ath is quite significant.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 31, 1:32 am, Lawrence D'Oliveiro wrote:
> In message <6e603d9c-2be0-449c-9c3c-
>
> bab49e09e...@13g2000prl.googlegroups.com>, Carl Banks wrote:
> > It's not Python that's the issue. The issue is that if you have a
> > module with a .dll extension
On Oct 31, 1:32 am, Lawrence D'Oliveiro wrote:
> In message <6e603d9c-2be0-449c-9c3c-
>
> bab49e09e...@13g2000prl.googlegroups.com>, Carl Banks wrote:
> > It's not Python that's the issue. The issue is that if you have a
> > module with a .dll extension
nux binaries are usually linked against a
versioned .so file, so a random command would refernce "libc.so.6"
rather than "libc.so".
I don't think that's necessarily the case for all Unix-like OSes,
though.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ng the exception)?
Just forget about exception handling. If you REALLY insist on doing
this, and I highly recommend against it, the best chance you have is
to try to hook into the importing process and load a module that uses
a custom dictionary object.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
attribute of
the K object:
class A(object):
def printme(self):
print "I am A"
class B(object):
def printme(self):
print "I am B"
class K(object):
def __init__(self, value=0):
if value == 0:
self.plugin = A()
print "__init__ A"
using it when the inspect module tries to import re.
Python is documented as behaving this way, so this is not a bug.
It is arguably poor design. However, Guido van Rossum already ruled
against using a single package for the standard library, and its not
likely that special case code to detect accidental name-clashes with
the standard library is going to be added, since there are legitimate
reasons to override the standard library.
So for better or worse, you'll just have to deal with it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ile with an updated timestamp?
Only thing I can think of, and if so it's probably not something you
want to turn off.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ems to short and innocent for a
function this magical.
Is the docstring expected to be formatted according to some
convention? I don't recognize a docstring convention in the example,
but then I don't bother with them much in my own code, that's why I
ask.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Nov 7, 3:44 pm, Yuv wrote:
> On Nov 8, 1:33 am, Carl Banks wrote:
>
> > Is the docstring expected to be formatted according to some
> > convention?
[snippage]
> We tried to comply to PEP 257 and we're open to suggestions on this.
Ah, so we finally get to the ans
same
growth algorithm. (Although in this case since the extend doubles the
size of the list it most likely reallocates after each call.)
[None]*N is linear time and is better than growing the list using
append or extend.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
for tons of examples.
Arguing that there are good reasons to allow killing threads isn't
going to get you very far. The language developers already know
killing a thread is useful, yet the disallowed it anyway. The
drawbacks were judged too severe (it makes enforcing invariants pretty
#x27;s no use for it in Python. Unless
you're programming DMA transfers or something like that, there's no
use for it in C, either.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
you just pass it a logical address, or an
object that supports buffer protocol, and it does the rest.
It seems just getting a physical address and starting a DMA transfer
from it is prone to danger if memory pages are discontiguous (and they
often are), but maybe OSes these days can handle that automatically.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
s important enough". This, even though it's more
useful than you are giving it credit for. It's a minor improvement.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ng so that
you can bind something other than the condition if need be.
if m with m as re.match(regexp,command):
Moot point for the next two years, and probably forever as I doubt it
would ever happen.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Nov 10, 9:37 pm, Steven D'Aprano
wrote:
> On Tue, 10 Nov 2009 20:13:21 -0800, Carl Banks wrote:
> > On Nov 10, 7:12 pm, Steven D'Aprano
> > wrote:
> >> On Tue, 10 Nov 2009 12:45:13 -0800, Bearophile wrote:
> >> > r:
>
> >> >> i
On Nov 10, 9:44 pm, Terry Reedy wrote:
> Carl Banks wrote:
>
> > r didn't actually give a good example. Here is case where it's
> > actually useful. (Pretend the regexps are too complicated to be
> > parsed with string method.)
>
> > if re.matc
On Nov 11, 4:12 pm, Steven D'Aprano
wrote:
> On Wed, 11 Nov 2009 03:52:45 -0800, Carl Banks wrote:
> >> This is where a helper function is good. You want a dispatcher:
>
> > No I really don't. I want to be able to see the action performed
> > adjacent to t
C++ program sometime.
>
> Go doesn't support inheritance, so C++ is pretty much out. C
> is a lot closer, but still not all that close.
Well, it's hard to argue with not being like C++, but the lack of
inheritance is a doozie.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Nov 11, 8:42 pm, Carl Banks wrote:
> On Nov 11, 7:56 pm, geremy condra wrote:
>
> > On Wed, Nov 11, 2009 at 9:00 PM, Mensanator wrote:
> > > On Nov 11, 6:53 pm, kj wrote:
> > >> I'm just learning about Google's latest: the GO (Go?) la
braries, then numpy will be of no use. But I guess if you're using
pygame third party modules are ok. So get numpy, it'll make things a
lot easier. It can be a bit daunting to learn, though.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
globals" and "function calls have rather high overhead").
Obviously, given the problem you chose, you know you're going to have
to worry about speed from the beginning. But since not many of us
know speed details off-hand, you'll probably get a faster answer by
just running the speed tests yourself.
Having said that, I *suspect* the numpy approach I mentioned will be
quite a bit faster than using bit operations and recalculating BC, but
I really don't know.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
said he was doing it just for fun. I don't know
about you, but I find it much more fun to try to write fast Python
than to write the fast stuff in C. Not as effective, but more fun.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ortunately not all such decisions and justifications are collected
in a tidy place.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
x27;t as
> useful to them as having a flexible, powerful and lightweight editor
> which can easily be scripted to provide whatever ad-hoc features they
> need.
>
> I regard this as an example of the way pairing spreads knowledge.
That's the best justification for pair programm
= PyCObject_AsVoidPtr(cobj);
func(ival,sval);
Py_RETURN_NONE;
}
def yeah(x):
call_user_void_ptr(x,int(i),"text_argument")
print "pointer called"
In a pinch, you could call the function pointer from ctypes. Since
you're already writing a C extension I wouldn't recommend it as a
final solution, though.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Nov 16, 10:32 am, Steve Howell wrote:
> On Nov 16, 2:35 am, Carl Banks wrote:
>
>
>
> > On Nov 15, 2:52 pm, Steve Howell wrote:
>
> > > Does anybody have any links that points to the rationale for ignoring
> > > instance definitions of __getitem__ wh
1301 - 1400 of 2098 matches
Mail list logo
