On Feb 22, 9:58 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Fri, 22 Feb 2008 00:45:59 -0800, Carl Banks wrote:
> > On Feb 21, 6:52 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> >> mrstephengross wrote:
> >> >> What y
d things about C++ and various features that C++ implements. If you
try to defend C++ every time that happens, you won't last long here.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Feb 24, 12:32 pm, Lie <[EMAIL PROTECTED]> wrote:
> On Feb 18, 1:25 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
>
> > On Feb 17, 1:45 pm, Lie <[EMAIL PROTECTED]> wrote:
>
> > > > Any iteration with repeated divisions and additions can thus run the
>
ing numerical integration sometime with rationals, and tell me
how that works out. Try calculating compound interest and storing
results for 1000 customers every month, and compare the size of your
database before and after.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Feb 25, 2:04 am, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
> Carl Banks <[EMAIL PROTECTED]> writes:
> > Try doing numerical integration sometime with rationals, and tell me
> > how that works out. Try calculating compound interest and storing
> > results fo
uessed it--more effort.
Deterministic destruction would be a great thing if it weren't for all
the drawbacks. Until then I will choose the path of lesser effort by
letting GC take care of memory, closing my own files, and having lots
of expressive power and freedom.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
return _fun_A1(x,y,z)
def _fun_A(x,y,z):
# you know x is of type A
def _fun_A1(x,y,z):
# you know x is of type A1
class B1(B):
def _fun_A(x,y,z):
# overrides B._fun_A
In other words, subclasses only override _fun_type variants. fun is
left alone. Extend idea as needed for your needs.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ations for the productivity increase.
The productivity increase of the language appears to me as a more
likely explanation for the number of libraries you get "out of the
box".
:)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Feb 25, 9:41 am, Mensanator <[EMAIL PROTECTED]> wrote:
> On Feb 25, 12:58�am, Carl Banks <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Feb 24, 10:56 pm, Mensanator <[EMAIL PROTECTED]> wrote:
>
> > > But that doesn't mean they become less manageable
etattr__(self,attrname)
if hasattr(attr,"__call__"):
wrapper = self.thobject._wrapper_function
return functools.partial(wrapper,self.parent,attr)
return attr
clsdict = { '__init__': init,
'__getattribute__': getattribute }
return type(name,(base,),clsdict)
That's some pretty advanced stuff you're doing there, chief. My
examples probably wouldn't work out of the box, but hopefully it'll
give you enough ideas to do it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ly
> disappointing Lisp "successor", Arc, amongst the usual in-fighting and
> parade-dampening.
It looks like his main contribution was to get rid of superfluous
parentheses. Which, admittedly, is no small thing for Lisp.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
er returned 0.75 in any language I would drop that language.
Have fun dropping Python, then, chief. Integer division with / is
already deprecated, can be disabled ever since Python 2.4, and will be
wholly removed in Python 3.0.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
that the library wasn't trying to be
helpful and was just indicriminately letting side effects loose.
Shame on the writer in any case.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
e at
the time". Nobody would have come up with a silly rule like "x op y
must always have the same type as x and y" if computer hardware had
been up to the task when these languages were created.
>Very simple rule, used by very many traditional >programming languages.
On Feb 28, 9:36 am, Grant Edwards <[EMAIL PROTECTED]> wrote:
> On 2008-02-28, Carl Banks <[EMAIL PROTECTED]> wrote:
>
> >> Automatic conversions, okay... but converting a result when
> >> all inputs are of one time, NO...
>
> > People, this i
an. Please do me a personal favor:
Personal favor? Seriously, do you have stock in a C++ support company
or something? There's no need to take stuff like this personally.
> Don't
> hold the crappy course against C++.
C++ has so much badness to hold against it, there's no nee
ldn't be automatically ported to 3.0, then it was a big
strike against the proposal. That it could end up being a useful
transitional tool is nice, but it never seemed to be its primary
purpose.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
gt; ## 4349 2029 None
> ## 6703 8677 None
> ## 1879 1867 None
> ## 5153 5279 None
> ## 2011 4937 None
> ## 7253 5507 None
>
> This makes sympy worse than worthless, as it f***s up other modules.
Dude, relax.
It's just a bug--probably sympy is messing with the internals
d more common.
Newbies who aren't being alerted to this are getting a raw deal.
Thankfully old-style classes are getting the axe in Python 3.0 and
hopefully this confusion will go away.
Until you switch to 3.0, inherit your base classes from object; it
will ensure that more recent additions like properties and super()
calls work.
class Node(object):
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
e
most common arguments, and use classmethods for more obscure, less
common arguments (such as decimal or even float).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 3, 4:47 pm, Mensanator <[EMAIL PROTECTED]> wrote:
> On Mar 3, 2:49 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Mar 3, 3:40 pm, Mensanator <[EMAIL PROTECTED]> wrote:
>
> > > Notice anything funny about the "random" ch
On Mar 3, 7:24 pm, Mensanator <[EMAIL PROTECTED]> wrote:
> On Mar 3, 4:53 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Mar 3, 4:47 pm, Mensanator <[EMAIL PROTECTED]> wrote:
>
> > > On Mar 3, 2:49 pm, Carl Banks <[EMAIL PROTECTED]>
ge(3):
if a == i:
do_task[a]()
else:
do_default_task()
(Please never mind the trivialness of this example; I know you can
eliminate the for loop altogether; this is JUST an example.)
I keep this analogy in mind when using for...else to keep the
semantics straight.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 4, 10:55 am, "BJörn Lindqvist" <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 4, 2008 at 4:17 PM, Carl Banks <[EMAIL PROTECTED]> wrote:
> > > for ...:
> > > ...
> > > exhausted:
> > > ...
> > > broken:
> > &
s:
>>>import module
>>>c1 = module.Someclass
>>>module.Someclass = some_other_class()
>>>c2 = module.Someclass
>>>c1 is c2
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
cent news filter should be able not only kill a poster, but also
all followups to that poster recursively.
(No, I don't know of any that do that either.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
sure what you mean. Are you talking about the post subject
> > line (which I have never touched in any post)? If you're talking about
> > the OP's email address, that's Google's fault for cropping them.
>
> I'm talking about castironpi. I find his posts a waste of my time
"His" posts?
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 6, 11:41 am, "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Mar 2008 08:00:58 -0800 (PST)
>
> Carl Banks <[EMAIL PROTECTED]> wrote:
> > > I'm talking about castironpi. I find his posts a waste of my time
>
> > "His
you want to evaluate (locals()
could be a good choice for this).
Standard warning about usage of eval: don't use this with untrusted
input or Bad Things can happen.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
have to do is call it from
Python using subprocess module and you're set. (DO NOT use os.system
for this since it starts a shell process, which is unnecessarily slow,
and dangerous when passed user input.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
or more y's
> #for each y:
> q.put(y)
Why not just do it like that? With a few changes it'll work fine:
while q:
x = q.pop(0)
for y in process(x):
q.append(y)
And consider collections.deque for q instead of a list, though it
shouldn't make much of a
if some_other_break_condition:
break
else:
completed = False
if not completed:
It felt icky but we're all still here so it couldn't have been that
bad.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
000
> >>> y=1000
> >>> x is y
> False
>
> If either is a surprise, then understand that the "is" operator should
> probably *never* be used with immutable types.
Not quite: None is immutable but it's usually recommended to test for
it using is.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
orked well as a
cross-platform solution for me. The interfacing is the main
drawback. It's always a bit of effort to interface things, and to get
it working on multiple platforms, but I thought it was worth it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
PyGame would be a
good way to make a cross-platform "text-mode" game. It should be
pretty straightforward to simulate a text mode terminal using a grid
of sprites. (There might even be some third-party text terminals out
there.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
g else.
Want to tell us what you need it for? Perhaps we can suggest a way of
doing it that's appropriate in Python.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
h a better one. Instead of the cmp
methods above, use the key method. Instead of __cmp__ method for
overriding object operators, use the rich comparison methods: __lt__,
__gt__, and so on.
Python 2.x currently implements both cmp and rich comparisons at the
same time, but that creates a lot
ome
magic variables that affected Perl's compilation and couldn't do it
without a magic block that executed at compile time.
Python solved a similar problem by introducing __future__ imports.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
the top, before the function
definitions, to clearly show to a human reader what is necessary to
run the script.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
return cmp_fn(self.obj, other.obj)
> > return CmpWrapper
>
> Apparently I'm overlooking something obvious ...
>
> how is this supposed to work if __cmp__ is no longer
>
> being called? (Which was my understanding.)
It won't. In Python 3.0 you'd
e relevant.
>
> It's easy to fix in SGMLlib. It's just necessary to change
>
> except AttributeError:
> to
> except AttributeError, UnicodeEncodeError:
>
> in four places. I suppose I'll have to submit a patch.
FWIW, the stated goal of sgmllib is to parse the subset of SGML that
HTML uses. There are no non-ascii elements in HTML, so I'm not
certain this would be considered a bug in sgmllib.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 14, 6:37 pm, Alex <[EMAIL PROTECTED]> wrote:
> On Mar 13, 6:21 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
>
> > On Mar 13, 7:02 am, Bruno Desthuilliers
> > [EMAIL PROTECTED]> wrote:
> > > Alex a écrit :
> > > (sni)
>
> > >
em etc..
>
> The goal is not to build a new renderer or something; just a small
> program that I need to do some manipulations in bulk on a set of OBJs
What do you mean by "manipulate". There are lots of ways to
manipulate 3D objects; can you be more specific?
Carl Banks
iment, you can hereby consider it also failed.
He said "aside from the sponsor talks", chief.
You need one of these:
http://tinyurl.com/26owvg
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
being concerned about this organization?
(My only minor suggestion would be not to import the SpecificClass as
BaseClass, but instead with a name that's different from both, for
example, PublicClass. All that does is to avoid a tiny bit of
potential confusion down the road.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
nt native types in those "most other oo languages". For instance,
it would be kind of true in Java (for numbers only).
He probably didn't, though, and the idea that most oo languages use
references is questionable.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
else\
_Py_Dealloc((PyObject *)(op))
So, if the reference count goes down to zero, Py_DECREF calls
_Py_Dealloc to delete the object. _Py_Dealloc is the common point you
want.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
x.
I'll also point out that even in C++/Java/etc. you have occasions
where an instance variable doesn't do anything until a something
triggers it. You can look to the constructor to see what it's
initialized to, but it isn't really initialized to anything useful
until some meth
t
conditionally-useful variables are ok but it's evil for them to
conditionally-exist?
The former I don't agree with at all.
If it's the latter, I believe there is something to be said for
variables that exist when they are needed and don't when they're not.
However, I ack
On Jan 11, 5:02 pm, Paul Rubin <http://phr...@nospam.invalid> wrote:
> Carl Banks writes:
> > and where it was manipulated for that matter.
>
> > This criticism is completely unfair. Instance variables have to be
> > manipulated somewhere, and unless your object i
On Jan 11, 5:49 pm, Chris Rebert wrote:
> On Sun, Jan 11, 2009 at 3:15 PM, Carl Banks wrote:
> > On Jan 11, 3:31 pm, Chris Rebert wrote:
> >> On Sun, Jan 11, 2009 at 1:22 PM, Madhusudan.C.S
> >> wrote:
> >> > def somemethod(self, arg1):
> >>
On Jan 11, 5:41 pm, Paul Rubin <http://phr...@nospam.invalid> wrote:
> Carl Banks writes:
> > > The criticism is very valid. Some languages do support immutable
> > > variables (e.g. "final" declarations in Java, "const" in C++, or
> > >
On Jan 11, 6:42 pm, Paul Rubin <http://phr...@nospam.invalid> wrote:
> Carl Banks writes:
> > If so, what is it that's so evil about conditionally-existent
> > variables? (I'll leave the question open-ended this time.)
>
> I have found they make the code
On Jan 9, 6:11 pm, John Machin wrote:
> On Jan 10, 6:58 am, Carl Banks wrote:
>
>
>
> > On Jan 9, 12:36 pm, "J. Cliff Dyer" wrote:
>
> > > On Fri, 2009-01-09 at 13:13 -0500, Steve Holden wrote:
> > > > Aivar Annamaa wrote:
> > > >
On Jan 12, 12:32 am, John Machin wrote:
> On Jan 12, 12:23 pm, Carl Banks wrote:
>
>
>
> > On Jan 9, 6:11 pm, John Machin wrote:
>
> > > On Jan 10, 6:58 am, Carl Banks wrote:
>
> > > > On Jan 9, 12:36 pm, "J. Cliff Dyer" wrote:
>
>
On Jan 12, 5:26 am, John Machin wrote:
> On Jan 12, 7:29 pm, Carl Banks wrote:
>
>
>
> > On Jan 12, 12:32 am, John Machin wrote:
>
> > > On Jan 12, 12:23 pm, Carl Banks wrote:
>
> > > > On Jan 9, 6:11 pm, John Machin wrote:
>
> > >
> | <_sre.SRE_Match object at 0x00FD86B0>
>
> This is "messed him up"?
If you believe in waiting for bugs to occur and then fixing them,
rather than programming to avoid bugs, there is no helping you.
P.S. The "obvious" solution is wrong, although I'm not sure if you
were making some kind of ironic point.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ble annotation. The 1% of the time where I really want to use
> dynamism I don't see any problem with putting in an appropriate
> decorator, superclass, or whatever.
Well, I guess you are the sacrifical lamb so that everyone else can
take advantage of the dynamicism.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 13, 6:45 pm, "Russ P." wrote:
> On Jan 13, 3:07 pm, Carl Banks wrote:
>
> > I've seen no evidence that any Python project is moving even remotely
> > toward data encapsulation. That would be a drastic change. Even if
> > it were only a minor cha
On Jan 13, 9:50 pm, Carl Banks wrote:
> The cultural impact that would have on the
> community is far worse, IMHO, than any short-sighted benefits like
> being able to catch an accidental usage of an internal variable.
> Trust would be replaced by mistrust, and programming in Pytho
apsulation in sight on any system I worked on.
In fact, our engine simulation was a special-purpose object-oriented
language with--get this--no private variables. Some other systems I
worked on didn't even use scoping, let alone encapsulation.
Looks like my anecdote cancels out yours! Go
On Jan 14, 1:40 am, Steven D'Aprano
wrote:
> On Tue, 13 Jan 2009 20:17:08 -0800, Carl Banks wrote:
> > On Jan 13, 9:50 pm, Carl Banks wrote:
> >> The cultural impact that would have on the community is far worse,
> >> IMHO, than any short-sighted bene
On Jan 14, 2:44 am, "Russ P." wrote:
> On Jan 13, 11:51 pm, Paul Rubin <http://phr...@nospam.invalid> wrote:
>
> > Carl Banks writes:
> > > At GE there was no encapsulation in sight on any system I worked on.
> > > In fact, our engine si
es are more likely to use
LGPL than GPL software.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
respond to a wishlist request, though.
As a workaround, you can just cast the set to a tuple like this:
isinstance(x,tuple(s))
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ged to allow a type, or
any iterable the returns types (wherein every items of the sequence is
required to be a type). What's messy about that?
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 15, 1:08 pm, Duncan Booth wrote:
> Carl Banks wrote:
> > I don't see what the big deal is. Right now isinstance accepts a type
> > or a tuple of types. The code could be changed to allow a type, or
> > any iterable the returns types (wherein every items of th
A subclass can add either more slots or a dict.
Object of types defined in C can have arbitrary layout. For instance,
it could have a layout that looks like this:
reference count
ob_type
PyObject* a
PyObject* b
long c
float d
instance dict
A problem with Python slots and C fields is that, if you want to
inherit from a type with a non-trivial object layout, aside from the
dict and weakrefs, all of the subtypes have to maintain the same
layout (see Liskov substitutability for rationale).
Subtypes can add their own fields or slots if they want, though. So,
if a Python subtype wants to define its own slots on top of a type
with a non-trivial object layout, it has to know which base has the
largest layout so that it doesn't use the same memory for its own
slots. Hence tp_base.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
practical to share very large objects among seperate
processes.
For simple data like large arrays of floating point numbers, the data
can be shared with an mmaped file or some other memory-sharing scheme,
but actual Python objects can't be shared this way. If you have
complex
data (networks and heirarchies and such) it's a lot harder to share
this
information among processes.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
tation, which claims that multiple
asynchronous writes to the same shared_ptr results in undefined
behavior. That will not suffice for Python reference counting.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
. Py_LOCK2
(a,b), which guarantess that if in another thread is calling Py_LOCK2
(b,a) at the same time, it won't result in a deadlock. What's
disappointing is that the deadlocking possibility is always with you,
much like the reference counts are.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 22, 9:38 pm, Rhamphoryncus wrote:
> On Jan 22, 9:38 pm, Carl Banks wrote:
>
>
>
> > On Jan 22, 6:00 am, a...@pythoncraft.com (Aahz) wrote:
>
> > > In article <7xd4ele060@ruckus.brouhaha.com>,
> > > Paul Rubin <http://phr..
On Jan 22, 10:15 pm, Paul Rubin <http://phr...@nospam.invalid> wrote:
> Carl Banks writes:
> > 3. If you are going to use the low-level API on a mutable object, or
> > are going to access the object structure directly, you need to acquire
> > the object's mutex. Ma
with the value.
class Record(immutable_object,slots=['name','number']):
def __new__(cls,name):
number = db.lookup_number(name)
immutable_object.__new__(cls,name=name,number=number)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 23, 5:48 pm, Bryan Olson wrote:
> Carl Banks wrote:
>
> [...]
>
> > BTW, class instances are usually immutable and thus don't require a
> > mutex in the system I described.
>
> Then you are describing a language radically different from Python.
Bzzt.
H
equire a mutex. The dict would need it, of course.
It's customary to gloss over this technicality for convenience's sake
in most discussions, but it matters in this case.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
table stuff just to find the
> function to invoke.
Now that doesn't make sense at all. What is all this mutable stuff
you have to go through, and what does it have to do with the GIL-less
implementation? Can you explain further? Or are you just saying
it'll be slow.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 23, 10:55 pm, Bryan Olson wrote:
> Carl Banks wrote:
> > Paul Rubin wrote:
> >> Bryan Olson writes:
> >>>> BTW, class instances are usually immutable and thus don't require a
> >>>> mutex in the system I described.
> >>> T
On Jan 23, 11:45 pm, Bryan Olson wrote:
> Carl Banks wrote:
> > Classes in Python are mutable types, usually. Class instances are
> > (except for the refcount) immutable objects, usually.
>
> There's where we disagree. I assert that class instances are usually
> m
On Jan 24, 12:40 am, "Gabriel Genellina"
wrote:
> En Sat, 24 Jan 2009 06:06:02 -0200, Carl Banks
> escribió:
>
>
>
> > On Jan 23, 11:45 pm, Bryan Olson wrote:
> >> Carl Banks wrote:
> >> > Classes in Python are mutable types, usually.
On Jan 24, 12:33 am, Hrvoje Niksic wrote:
> Carl Banks writes:
> > Anyway, all you're doing is distracting attention from my claim that
> > instance objects wouldn't need to be locked. They wouldn't, no
> > matter how mutable you insist these objects w
On Jan 24, 12:24 pm, Carl Banks wrote:
> On Jan 24, 12:33 am, Hrvoje Niksic wrote:
>
> > Carl Banks writes:
> > > Anyway, all you're doing is distracting attention from my claim that
> > > instance objects wouldn't need to be locked. They wouldn't,
On Jan 24, 12:05 pm, Carl Banks wrote:
> The default metatype for Python classes would be
> mutable_dict_type, which is a type wherein the object itself would be
> mutable but it would still have all the mutator methods __init__,
> __setattr__, etc., but they could only act on the __d
Tkinter worked fine, BTW.
My questions are 1. is that really what Windows extension users are
expected to do, 2. if not, what else might be wrong, and 3. are there
any workarounds?
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
> In the expectation, I stay in 2.6
Whoa--it did NOT occur to me that the bug was in Python. Sure enough,
bug tracker has big thread about it, and a neat fix.
http://bugs.python.org/issue4566
Thanks. Reverting to 2.6.0 should suffice for now.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Sketchup is linked with msvcr80.dll.
I'm pretty sure 2.6.1 is compiled with 8.0. However, I think the
Visual C++ 8.0 uses msvcrt90.dll.
Take a look at this bug report to see if it's related to your issue:
http://bugs.python.org/issue4566
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Feb 9, 11:34 pm, Tim Roberts wrote:
> Carl Banks wrote:
>
> >I'm pretty sure 2.6.1 is compiled with 8.0. However, I think the
> >Visual C++ 8.0 uses msvcrt90.dll.
>
> No, the two digits of the DLL match the version number of C++. The
> confusion arises becau
ity, though not a very
likely one in this case: the behavior of isinstance can be
customized. It can happen unbeknownst to a user who subclasses a
class that does that.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ad that allows
you to do things like thread.join().
Simple locking will be same speed whether you use the threading or
thread module, because threading.Lock and thread.acquire return the
same type of object. This is an implementation detail, though.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
8)).view(recarray)
reshaped_data = reshape(data,(50,100))
intersting_data = reshaped_data[:,50:100]
A word of caution: Every instance of numpy.memmap creates its own mmap
of the whole file (even if it only creates an array from part of the
file). The implications of this are A) you can't use numpy.memmap's
offset parameter to get around file size limitations, and B) you
shouldn't create many numpy.memmaps of the same file. To work around
B, you should create a single memmap, and dole out views and slices.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
fficient to use the offset parameter
with numpy.memmap than it is to memmap the whole file and take a
slice.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
umpy.memmap can take
advantage of that if the user passes an offset parameter. One thing
you can't do with mmap's offset, but you can do with numpy.memmap, is
to set it to an arbitary value, since it has to be a multiple of some
large number (something like 1 MB, depending on the OS).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
n--or not--I'll post some things I've
considered, including a few approaches I've actually implemented. But
I don't want to taint everyone's ideas just yet.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Feb 19, 9:34 am, Lionel wrote:
> On Feb 18, 12:35 pm, Carl Banks wrote:
>
>
>
>
>
> > On Feb 18, 10:48 am, Lionel wrote:
>
> > > Thanks Carl, I like your solution. Am I correct in my understanding
> > > that memory is allocated
On Feb 19, 10:00 am, sturlamolden wrote:
> On 19 Feb, 03:13, Carl Banks wrote:
>
> > The offset parameter of mmap itself would be useful to map small
> > portions of gigabyte-sized files, and maybe numpy.memmap can take
> > advantage of that if the user passes an offset
On Feb 19, 10:36 am, Lionel wrote:
> On Feb 19, 9:51 am, Carl Banks wrote:
>
>
>
>
>
> > On Feb 19, 9:34 am, Lionel wrote:
>
> > > On Feb 18, 12:35 pm, Carl Banks wrote:
>
> > > > On Feb 18, 10:48 am, Lionel wrote:
>
> >
On Feb 19, 6:57 pm, Ron Garret wrote:
> I'm writing a little wiki that I call µWiki. That's a lowercase Greek
> mu at the beginning (it's pronounced micro-wiki). It's working, except
> that I can't actually enter the name of the wiki into the wiki itself
> because the default unicode encoding on
ded. If you do use os.chdir(), then early in your script script,
add a line such as "sys.path[0] = os.getcwd()". Then, no matter where
you are, always import the file relative to the starting directory.
So always use "from test.data import DATA", even after you os.chdir().
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Nov 28, 3:15 am, Ben Finney <[EMAIL PROTECTED]>
wrote:
> Carl Banks <[EMAIL PROTECTED]> writes:
> > I like to think that "import abc" always does the same thing
> > regardless of any seemingly unrelated state changes of my program,
> > especially sinc
On Nov 28, 3:24 am, Viktor Kerkez <[EMAIL PROTECTED]> wrote:
> On Nov 28, 9:35 am, Carl Banks <[EMAIL PROTECTED]> wrote:
>
> > However, I'm not so sure the effect of os.chdir() on the import path
> > is a good idea.
>
> I'm not actually using os.chidi
601 - 700 of 1709 matches
Mail list logo
