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
On Feb 18, 10:48 am, Lionel wrote:
> Thanks Carl, I like your solution. Am I correct in my understanding
> that memory is allocated at the slicing step in your example i.e. when
> "reshaped_data" is sliced using "interesting_data = reshaped_data[:,
> 50:100]"? I
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:
>
> >
nformation.
>>> def f(*args): print args
...
>>> f()
()
>>> f(1)
(1,)
>>> f(1,2)
(1, 2)
>>> f(1,2,3)
(1, 2, 3)
>>> f(1,2,3,4)
(1, 2, 3, 4)
>>>
I could see the logic in always or never having a trailing comma. What
I don't underst
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
On Nov 28, 2:59 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> Carl Banks <[EMAIL PROTECTED]> writes:
> > On Nov 28, 3:15 am, Ben Finney <[EMAIL PROTECTED]>
> > wrote:
> > > This is resolved in the Python 2.x series by implementing PEP 328
> > > h
On Nov 28, 11:51 pm, Carl Banks
> Absolute versus relative imports don't have anything to do with the
> issue here. PEP 328 concerns itself with imports relative to the
> executing module in package space. It has nothing to do with imports
> relative to the current directory
a second engine object
(maybe of a different type altogether), and play the very same Bar
objects with that engine instead.
> I'm hoping this is a common trap I've fallen into; I just haven't been able to
> get my head around it. (I'm a musician...)
Well I think it looks pret
own syntax (and the print
statement had lots of peculiarities), whereas all function calls
follow the same syntax.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
space pollution.
IMHO, namespace pollution occurs when you do things like "from module
import *"; there is no pollution when you control the whole namespace
yourself.
Having said that, I do use local functions without closures here and
there, when it's something either too silly or too specific to
introduce a module-level function for. Judgment call, mostly, but
typically I go to the module level.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
bit of time. If it is a concern, run it through a
profiler to get an idea of how much it costs, so you can make an
informed decision.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 3, 7:51 pm, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On behalf of the Python development team and the Python community, I
> am happy to announce the release of Python 3.0 final.
Congratulations! This is a great day for the Python community.
Carl Banks
--
http://mail.python
ent, so the best you can do
is improvise something like this:
def make_counter(start_num):
start = [start_num]
def counter():
start[0] += 1
return start[0]
return counter
You can access variables from an enclosing scope starting from Python
2.2 (from 2.1 with from __futu
developers.
So stop complaining. If you don't want to take a few minutes a year
to visit Python.org to see what changes are planned for upcoming
releases, then feel free to use a language like Java that has the
corporate backing to keep bad decisions around for decades.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
grown in popularity in spite
of (and, I would say, in part because of) a history of backward-
incompatible changes with every major release.
It's not like Python has ignored the users; it's been very careful and
considerate when making backwards-incompatible change. This
Warren here who have distributed codebases they can't
easily fix up, and who were neither smart nor informed enough to avoid
using "as", are a pretty tiny minority, I would guess.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ject.as(class_reference) is highly
convenient because it mirrors textually the Java convention of
object.asFloat" will go over a lot better than "object.as
(class_reference) is the only obvious concise answer".
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
7;t think it's really advisable to be completely ignorant of
the 2.x difference even if one intends to start with 3.0. There is a
lot of code and material out there for 2.x, and until these start to
be widely available for 3.x, people will sometimes have to make do
with the 2.x stuff.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
the following are equivalent:
def foo(): return bar
foo = lambda: bar
I had been -0 on this, but now I think I'm -1.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
#x27;t chime well with this approach.
> > "self" is a speaking identifier, "$" isn't.
>
> Is "@" a "speaking identifier? How about "#" and "!="? Last I heard,
> they were all part of Python.
None of them are identifiers. $, used as proposed, would be.
(Then again, _ is an identifier.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
e proposal is viable.
>
> > >> I'd like this new way of defining methods, what do you guys think?
> > >> Anyone ready for writing a PEP?
>
> > >> Cheers,
> > >> Daniel
>
> > >> --
> > >> Psss, psss, put it down! -
ing like def a.b() would be. The above statement is not
equivalent to:
self.method = lambda: 1
but I think that's what it ought to be, in general.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 6, 4:39 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
> On Dec 6, 1:21 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Dec 6, 9:12 am, "Russ P." <[EMAIL PROTECTED]> wrote:
>
> > > On Dec 6, 1:02 am, Antoine De Groote &
the type
while preserving the semantic value as much as possble, so cast is a
perfectly appropriate name for it.
(BTW, in C++, even pointer-to-pointer static casts don't always
preserve the bits.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 6, 6:42 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
> > But it's ugly. No amount of rationalization will make it not ugly.
>
> The dollar sign is ugly? I beg to differ.
Nope, you're wrong.
Carl Banks
(See where this is going?)
--
http://mail.python.org/mailman/listinfo/python-list
for once again Python
showed what the best way to enter unpleasant waters is: with a lot of
restraint--but a "better parsing framework" that eliminated keywords
would cause lots of confusion.
And finally: it's just plain bad style to use a syntactic element as
an identifier, even when allowed.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
(self):
return False
def create_date_from_dbf_cell(dbf_cell):
if dbf_cell.empty():
return NullDate()
return ValidDate(dbf_cell.value)
If you do this, you don't have to muck around with __getattr__ or
__new__ or snooping to datetime.date's class dict anything like that.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
he language.
I think mostly it's just a logistical issue. It's reasonable for a
class's attributes to be objects of that class (the datetime.date
class is a perfect example of when it's useful). It would be
preferrable to assign such objects inside the class scope like all
ot
On Dec 10, 12:42 pm, cm_gui <[EMAIL PROTECTED]> wrote:
> Python is SLOW. And I am not comparing it with compiled languages
> like C.
> Python is even slower than PHP!
cm_gui is TROLL. And I am not compring it with bots like Aaron
Castironpi Brody. cm_gui is even troller than
er,NullDate):
return True
return False
# note: in Python 3.0 you would want to throw exceptions
# for unexpected types
Then use ValidDate instead of datetime.date when the date is
specified.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
terminal the underlying I/O is usually line-buffered, meaning
that nothing actually gets output until a newline character is sent.
Therefore we have to call sys.stdout.flush() to flush the buffer
manually.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 14, 5:52 am, Karlo Lozovina <_kar...@_mosor.net_> wrote:
> Carl Banks wrote
> innews:69d2698a-6f44-4d85-adc3-1180ab158...@r15g2000prd.googlegroups.com:
>
> > Unless you are referring to some wget screen mode I don't know about,
> > I suspect wget outputs
ronounce* their
possessives exactly as nouns do. They just spell them differently,
for no really good reason.
The way I see it, if the rule had been, "Use an apostrophe for any
word that forms it's possessive by adding an s or z sound", it would
have been less inconsistent.
out on you with
> >> unicode-errors.
>
> >> So, IMHO the current behavior is desired.
>
> > So if I want to overload something in my custom class, so that I get a
> > nice string whether it's printed directly, or as part of a container, what
> > is the recommendation? Overload both __str__ and __repr__?
>
> Yep.
I would say no.
__repr__ should be specific--something that when evaled yields an
equal object, if possible--about what the object is. Overloading
__repr__ to return an unspecific human-readable message is a mistake,
and will frustrate users who are debugging, logging, inspecting
objects at the interactive prompt.
Neal's problem seems to be with the behavior of dict's __str__ method,
which prints repr() of objects when he wants str(). That is intended
behavior, like it or not, so I would say the appropriate thing is not
use dict's default printed representation, and just write a custom
formating function for dicts.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
he
> transition to C programming for this student. Lets not forget how
> important C is!
C programmers who learn Python have to learn all kinds of new things,
a new string formating method would be a minor one. As for everyone
else, they'll probably have an easier time of it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ble to maintain your own hacked-
up fork of a highly wrought out programming language?
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
hey would have at least deprecated or got rid of the %
operator, because that's ugly. There's no reason they couldn't have
added another method for printf-style formating, e.g.:
"The answer is %s.".sprintf("yes")
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
doubt over whether he had any credibility, but now
there is no doubt that he none at all, so he's not worth replying to,
so I don't. I suggest everyone else does likewise and ignores the
fool.
If you have to followup, at least keep your reply to something short
and witty, like, &qu
what encoding to use,
since it ostensibly has to parse the header. It's reasonable that IF
a url request's "Content-type" is text, and/or the "Content-encoding"
is given, for urllib to have an option to automatically decode and
return a string instead of bytes. (For all I know, it already can do
that.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
w
multidimensional indexing and slicing, most notably numpy.
So, for instance, if you were install numpy, you could get
multidimensional arrays and slice 'em up however you'd like:
import numpy
a = numpy.array([[1,2,3],[4,5,6],[7,8,9]])
print a[1:3,0:2]
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
er, you could create an IdentitySet class that
subclasses set and wraps the methods so that they automatically apply
wrap and unwrap the arguments on their way in and out (I'd bet there's
already a cookbook recipe to do that).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
usually entail a performance penalty (since the
compiler has to be invoked for every call), so please use them only
what they were intended for.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
s supplied through the input.
To be honest I am a little concerned over the more-or-less knee-jerk
suggestions to refactor this into a highly object-oriented approach.
For the task at hand the OP's approach is fine (aside from the use of
exec).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
change it to do a search by a tag class attribute if you wish;
left as an exercise.
> 2. Update A1Factory in each module which implements refinements.
> _Very_important_, how do I make sure each module is hit - so that the
> factory is updated? The module EN will be looking only at base module,
> so the other modules is not hit. I will have to import every module in
> EN - just to make sure that the A1Factory updation code is hit. This
> looks in-elegent.
Not worth it. The straightforward, good-enough way above is good
enough.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Gabriel Genellina wrote:
> En Mon, 29 Dec 2008 19:47:51 -0200, Carl Banks
> escribi�:
> > On Dec 29, 10:51�am, Kottiyath wrote:
>
> >> Module Factory:
> >> A1Factory: {'B1Tag':1.1.B1, 'C1Tag':1.2.C1, 'D1Tag':1.3.D1'}
> >&g
en you should
use camel case for the protocol primitives but prepend an underscore.
4. If you answered, "I include those functions in the same namespace
because I am following the example of other language bindings in Perl,
Java, Ruby, etc.,", then figure out whether it's important to b
string
and use the Reflection API to get at it at run-time.
Python, OTOH, is very dynamic, so there is not much demand for spiffy
introspection APIs. Functions and classes are ordinary objects, so if
you don't know what function to call or class to use at compile-time,
you can just pass t
on
module. Yes, that can be done.
See PEP 302, Import Hooks:
http://www.python.org/dev/peps/pep-0302/
Python's standard importer looks for files with *.py, *.pyc, *.pyd, or
*.so extensions. You could write an importer that looks for *.dsl
files, and, instead of loading it as a Python file, invokes your DSL
parser.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
a function that accepted integers, and 442 was
an invalid value, and the function failed silently in a unit test,
they would also consider whether it should instead fail loudly.
It's always a judgment call how much to screen for bad input, but type
errors aren't different from any o
lute (since PyImport_Import
calls it) so the two modules should both use absolute imports in 2.6.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
):
widget and self would always be the same object, and that's just a
waste.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
;s zipfile
module just assumes it's corrupted.
The following post from a while back gives a solution that tries to
snip the comment off so that zipfile module can handle it. It might
help you out.
http://groups.google.com/group/comp.lang.python/msg/c2008e48368c6543
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
in questionable practices like relying on accidental side
effects, rather than taking the time to try to program robustly. I
expect people with that style of programming will have many more
issues with the transition.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
cookbook.
He probably wrote his own faster than it would have taken him to
search for existing systems, and as an added bonus wouldn't have had
to work around all those things that are almost but not quite the way
he wanted.
Cut him some slack.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
n on source
forge, not the ancient version of python-mode in the Python
repository) has a fix for this issue. It doesn't look like there's
any way to browse the subversion any more, though.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 16, 12:21 pm, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
> Carl Banks a écrit :
>
> > On Oct 14, 1:05 pm, Bruno Desthuilliers
> > <[EMAIL PROTECTED]> wrote:
> >> - a slightly less but still annoying problem (I wouldn't
> > call it a b
On Oct 17, 4:25 am, Damien Wyart <[EMAIL PROTECTED]> wrote:
> * Carl Banks <[EMAIL PROTECTED]> in comp.lang.python:
>
> > The python-mode.el on Subversion (python-mode's Subversion on source
> > forge, not the ancient version of python-mode in the Python
>
threading.Condition()
def f():
global counter
c.acquire()
while counter % 1 == 0: # == 1 for the other thread
c.wait()
do_something()
counter += 1
c.notify()
c.release()
The reason threading.Condition is required and not a simple lock is
that simply acquiring the lock is not enough; the counter must be in
the right state as well.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
the lock
almost always acquired it right back, since there was only a tiny
window in which a thread switch could take place. Obviously the
wisdom of what he was doing was suspect, but the OP was right in that
a manual GIL release would allow a thread switch and could have helped
avoid starvation in that case.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
this is
> that the only way to insert something new inside a queue
> is by doing it from scheduled function.
Yeah, that does happen.
I often used this sort of thing (pre-Python days, so a long time ago)
in single-threaded, real-time simulations.
Don't know mcuh about the sched module, but time scheduling in general
doesn't need multithreading, not one bit.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 21, 7:49 am, MRAB <[EMAIL PROTECTED]> wrote:
> On Oct 21, 10:22 am, Carl Banks <[EMAIL PROTECTED]> wrote:
>
> > On Oct 21, 5:09 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
> > wrote:
>
> > > En Tue, 21 Oct 2008 04:58:00 -0
o tried this with read(), and I get the same
> results. It's not acceptable that I have to close and reopen the file
> before every read when I'm doing random record access.
You can call f.flush() to force it to discard the cache. Or use
unbuffered I/O. Better yet, get rid of file I/O altogether and use an
memory mapped file.
> So, is this a bug, or am I being stupid?
Well, it's not a bug, so
Seriously, I advise you not to submit a bug report. Doesn't mean
you're stupid, maybe you didn't know about unbuffered I/O or the
flush() method. That just means you're uneducated. :) But please
leave seek() out it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
working (for pdf that is.) any
idea if pdf conversion is working?
Carl K
--
http://mail.python.org/mailman/listinfo/python-list
eports.
what this is for: http://chipy.org/V4l2forPyCon
Carl K
--
http://mail.python.org/mailman/listinfo/python-list
Michael Torrie wrote:
> Carl K wrote:
>> I need to convert pdf to png, which imagemagic convert does, I think by using
>> ghostscript. a little over a year ago I tried with some imagemagic (there
>> are
>> at least 2 i think) and neither seemed close to working
t;
> > Bye,
> > bearophile
>
>
> Since python is dynamic language, I think it should be possible to do
> something like this:
>
> a = list([1, 2, 3, 4, 5], implementation = 'linkedlist')
> b = dict({'a': 'A'}, implementation = 'bi
why I hope someone else has done it.
I'm guessing no.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
,
bases,clsdict)
obj = cls()
return obj
class load(Action):
__metaclass__ = self_instantiate
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ct()
self.false_surrogate = object()
super(special_dict,self).__init__(*args,**kwargs)
def __getitem__(self,value):
if value is True:
value = self.true_surrogate
elif value is False:
value = self.false_surrogate
super(special_dict,self).__getitem__(value)
## etc.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
de I don't need,
too, and I never concern myself with them, so it's probably a
misplaced irk.
Go ahead and use it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
if I wanted that type of
> functionality I would have to use os.dup, fork, exec, which meant
> reinventing the wheel. I overcame the issue of dealing with msvcrt
> and _subprocess under windows by requiring python24 or greater under
> windows.
Distributing the interpreter doesn't
d safer ways to do this
(use getattr, setattr, globals, and locals built-ins). And if you
find yourself using them a lot, it's a red flag that you should be
using dicts instead.
- Don't ever pass any data to exec or eval that you didn't either
write, or thoroughly inspect, yourself. Especially don't pass it any
data you received over the network. You have to be the super extreme
expert that Steven described, and own a lot of liability insurance,
befor you can do that.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
self well, and it might
have even been a real issue. Python is not, unfortunately, the
easiest language to deploy applications in.
I don't think there is any deployment difficulty so great that I would
ever chose VBscript, but opinions might differ.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
801 - 900 of 2081 matches
Mail list logo
