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
x instead.
Hopefully this example will help you understand what doing this
entails and what you have to do to get it work.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ble
> > mnemonics. E.g. on a US keyboard layout, you could get ≠ by holding down
> > the Option key and typing =.
>
> They all still seem to work -- presumably generating the
> appropriate unicode characters now instead of MacRoman.
³It¹s about time.²
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ation of isinstance to advertise that your class implements
MutableMapping, which is the right way to do it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
to mechanically
split off methods into different files, you should consider whether
there's a way to refactor that one big class into smaller ones. Then
the problem you have goes away.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
illa_object = PyObject_CallObject(vanilla_type,0);
Definitely not the most straightforward thing to do from C.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
tialized. See PEP 311 for details.
http://www.python.org/dev/peps/pep-0311/
I also suggest that if you want people to be more receptive to write
your replies after the quoted text. That is the custom in this
newsgroup/mailing list.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
python.
Python is open source, anyone can look at the implementation to see
how it behaves. The source code is the right place to seek answers
about arcane minutae like when os.path.normpath appends a backslash.
Not the Python docuementation, and definitely not this newsgroup.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
setattr(tee,x,function)
The business with method.im_func is because in Python 2.x the getattr
on a class will actually returns an unbound method, so you have to get
at the actual function object with im_func. In Python 3 this is not
necessary.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
lly visible and any sane advice you ever
heard about globals is to use descriptive names. I instinctively use
adjectives, compound words, and abstract nouns for the names of all my
modules so as to be more descriptive, and to avoid name conflicts with
classes and variables.
Also learn to
send_email.py" or "sort_email.py" or if it's a
library module of related functions, "email_handling.py". Modules and
scripts do things (usually), they should be given action words as
names.
(**) Questionable though it be, if the Standard Library wants to use
an "innocuous" name, It can.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
eady is that way, chief.
I think you're misunderstanding what's wrong here; the CWD doesn't
have anything to do with it. Even if CWD isn't in the path you still
get the bad behavior kj noted. So now what?
Python's importing can be improved but there's no foolpr
On Feb 2, 2:49 am, Jean-Michel Pichavant
wrote:
> Carl Banks wrote:
> > Name your modules "send_email.py" or "sort_email.py" or if it's a
> > library module of related functions, "email_handling.py". Modules and
> > scripts do things (
On Feb 2, 11:07 am, Jean-Michel Pichavant
wrote:
> Carl Banks wrote:
> > On Feb 2, 2:49 am, Jean-Michel Pichavant
> > wrote:
>
> >> Carl Banks wrote:
>
> >>> Name your modules "send_email.py" or "sort_email.py" or if it's a
>
On Feb 2, 5:49 pm, Steven D'Aprano
wrote:
> On Tue, 02 Feb 2010 12:26:16 -0800, Carl Banks wrote:
> > I did not propose obvious module names. I said obvious names like
> > email.py are bad; more descriptive names like send_email.py are better.
>
> But surely send_email.
On Feb 3, 8:55 am, Nobody wrote:
> On Tue, 02 Feb 2010 10:38:53 -0800, Carl Banks wrote:
> >> I don't know if that's necessary. Only supporting the "foo.h" case would
> >> work fine if Python behaved like gcc, i.e. if the "current directory&qu
On Feb 2, 8:52 pm, Steven D'Aprano
wrote:
> On Tue, 02 Feb 2010 19:55:15 -0800, Carl Banks wrote:
> > On Feb 2, 5:49 pm, Steven D'Aprano
> > wrote:
> >> On Tue, 02 Feb 2010 12:26:16 -0800, Carl Banks wrote:
> >> > I did not propose obvious module nam
Error: 'module' object has no attribute 'help'
>
> > the same with other commands:
> > .databases
> > .tables
> >http://www.sqlite.org/sqlite.html
>
> No.
Well actually you can, sort of. For instance:
os.system('sqlite3 :memory: .help')
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
conforming to UAP,
therefore it doesn't need it, and there's no reason to adhere to it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
sive question is whether the path should be a subset of string.
Under ordinary circumstances it would be a poor choice for inheritance
(only a few string methods would be useful fot a pathname), but some
people were fiercely adamant that paths should be passable to open()
as-in (without having to explicity convert to string). IIRC, the guy
who maintained path wavered between subclassing and not subclassing
str. I don't remember if the idea of modifying open to accept path
objects came up.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
lf,other)
I wouldn't recommend it. Just use a function call with three
arguments.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
gin
|
|
V
Start Editor
|
|
V
Write Code <+
| |
| |
V |
Run Python |
| |
| | No.
V |
Did it do what you want?
|
| Yes.
|
V
Stop.
HTH.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
his would be very helpful for all users.
>
> Huh??? What aspect of Python were you thinking of mapping out?
>
> Your example us a bad ascii art graph of -- I've no clue what?
Usenet servers.
Back in the day people had these in their .sigfiles
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
eptional-case
typical-case
No, it deosn't bother me in the least that I sometimes test for the
exceptional case and sometimes for the typical.
Whenever there is no typical case or exceptional case I'll go for the
simpler condition.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
is to try to identify what's causing the error. Whatever code
you removed when the error disappears should give you a clue what's
causing it. Then, if need be, you can come back and post details. If
you manage to get the program to a small size without eliminating the
problem, you can post it here.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Feb 16, 10:32 am, Casey Hawthorne
wrote:
> Hubris connects Ruby to Haskell, will there be such a connection
> between Python and Haskell?
I would have expected Hubris to link Ada and Common Lisp together.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
n the fly based on parameters, you
> can encode this into the nice name, of course.
>
> Sadly, often bold statements about a language are made in ignorance.
I don't see what he said was any kind of a bold statement about a
language, arguably it was about the
On Feb 19, 10:30 pm, Lawrence D'Oliveiro wrote:
> In message , Rhodri James wrote:
>
> > In classic Pascal, a procedure was distinct from a function in that it had
> > no return value. The concept doesn't really apply in Python; there are no
> > procedures in that sense, since if a function termi
a value
So if your language distinguishes between procedures and functions, it
manifestly has to distinguish between statements and expressions, but
there's no reason that the converse has to be true, expecially if an
expression is a legal statement.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
od of non-activity, or is that something
best left for the host to manage?
I'd guess that modern web hosts would prefer that processes stay
running, even if they go long periods without use, rather than having
to periodically restart processes.
Carl Banks
--
http://mail.python.org/mailman/listi
s attributes is a good idea. If you are inputing
or calculating the names, then it's better to use a dict.
** The one place where Python does have references is when accessing
variables in an enclosing scope (not counting module-level). But
these references aren't objects, so you can't store them in a list, so
it can't help you:
def f():
s = []
a = 1
def g():
print a
s.append(a)
g() # prints 1
a = 2
g() # prints 2: g's a is a reference to f's a
print s # prints [1,2] not [2,2]
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
underlying data like that when you take
slices. For instance, this probably works the way you want:
a = numpy.array([1,2,3,4,5,6])
b = a[:3]
c = a[3:]
None of the actual data was copied here.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Feb 20, 10:50 pm, Steven D'Aprano wrote:
> On Sat, 20 Feb 2010 22:31:44 -0800, Carl Banks wrote:
> > The one place where Python does have references is when accessing
> > variables in an enclosing scope (not counting module-level).
>
> What makes you say that?
>
is and is better to use a
> > separate dict instead, but I'll assume you know what you're doing and
> > have good reasons to disregard the standard advice due to your
> > use-case.
>
> Why is it unwise?
He didn't say it was unwise. He said it's usually not wise.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
define __hash__ to raise
NotImplementedError so that Python will refuse to use them in sets or
as dictionary keys:
def __hash__(self): raise NotImplementedError
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
hat languages do, of if there are any with a
trinary operator that also takes a threshold.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
xception with a C statement,
and catch and print it in the very next line. The exception doesn't
exit from Python code so there are no lines to print.
What line/file data you do expect to see?
If you want to see C line/file informnation you have to use a debugger
like gdb, as Steve Holden said.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
;d'# doesn't fail but should
assert tup.A == 'd'
assert tup[0] == 'd' # fails but, granted you allow mutabilty,
shouldn't
The best way to do what the OP wanted (originally) is this, no
subclassing necessary:
def my_named_tuple(names,values):
return namedtuple('ad_hoc_named_tuple',names)(*values)
As for the OP's second problem, to append named items, I'd first
consider whether I'm thinking about the problem correctly, and if so,
go with a subclass of list and overriding __getattr__. Probably one
of the rare cases I would override __getattr__ other than a proxy
class.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
1201 - 1300 of 1709 matches
Mail list logo
