Re: harmful str(bytes)
On Thu, 07 Oct 2010 23:33:35 +0200 Hallvard B Furuseth wrote: > > The offender is bytes.__str__: str(b'foo') == "b'foo'". > It's often not clear from looking at a piece of code whether > some data is treated as strings or bytes, particularly when > translating from old code. Which means one cannot see from > context if str(s) or "%s" % s will produce garbage. This probably comes from overuse of str(s) and "%s". They can be useful to produce human-readable messages, but you shouldn't have to use them very often. > I really wish bytes.__str__ would at least by default fail. Actually, the implicit contract of __str__ is that it never fails, so that everything can be printed out (for debugging purposes, etc.). Regards Antoine. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Wed, Oct 06, 2010 at 05:28:13PM -0400, Terry Reedy wrote:
> On 10/6/2010 7:14 AM, Antoon Pardon wrote:
>
> >>That right-hand-half-open intervals (i.e. a<= i< b, equivalently [a,
> >>b) ), which are what Python uses, are to be preferred.
> >>(See aforelinked PDF: http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF)
>
> This specifically discusses subsequences of 'natural numbers'.
Sure, but I don't think we should limit ourselves to subsequence of
natural numbers. It is my impression that orginally slices were
also limited to indicating subsequences of natural numbers. This
original limitation, has guided its semantics that resulted in
what we have now,
> >The problem is that the slice notation is sometimes handy in situations where
> >an open interval doesn't allow easily to mark what you want.
> >
> >For instance I have at one time implemted a Tree. This is a dict like
> >structure
> >but it allows to visit the keys in order. Because there is an order, slice
> >notation can make sense. e.g. if T is a tree with names as keys,
> >T['bea':'mike']
> >is a subtree where we have for each key that 'bea'<= key< 'mike'.
>
> >But what if I wanted a subtree where 'mike' was still included, but nothing
> >further?
> >Or what if the keys were floats or tuples and I wanted an inclusive upper
> >boundary?
>
> Strings and tuples are not natural numbers, but do have least
> members ('' and ()), so the bottom end had better be closed.
Why? The fact that we have a bottom element in the item space,
doesn't imply that the sequence I need is easiest defined by
using an inclusive lower limit. What if I wanted all none-empty
strings/tuples keys in the tree? The easiest way to specify that
would be by saying the key needed to be larger than the empty
string/tuple. If the keys were strings I could fudge it by starting
with chr(0), but what value should use as start, if I wanted all
non-empty tuples?
> Since
> substracting strings and tuples in meaningless, the argument of
> having stop-start == number of items does not apply. Floats can be
> subtracted, but the result in not a count of included items. So
> write the .__getitem__ method of *your* class how it best fits your
> use-cases.
My use cases depend on the specific problem I need to solve. Sometimes
the problem is easiest solved with an inclusive limit, sometimes it
is with an exclusive limit. The slice notation although at first sight
a natural way to specify the boundaries, seems on closer inspection
to be too limited.
> Just be aware that an inclusive upper boundary means that
> s[a:b]+s[b:c] will no longer be s[a:c] because b will be duplicated.
> Let me also point out integer slices for builtins are adjusted to
> that they refer to actual slice positions. This is harder to do with
> strings;-). Also, suppose you want all strings beginning with 'a' or
> 'b'. With an open upper end, Tree['a':'c'] will do that. With closed
> upper end, you would need
> Tree['a':'bbb'] or somesuch.
Yes I know. I'm starting to think about aproaching this in a different
manner.
> >And what if you needed the reverse sequence. If you start with inclusive
> >limit,
> >the reverse of a<= item<= b is b>= item>= a. If the second limit is to be
> >exclusive the reverse of a<= item< b becomes (b - 1)>= item> (a - 1).
>
> Slices with positive strides can be defined and understood in terms
> of slice positions before the first item, between all successive
> pairs of items and after the last. By this same definition and
> understanding, s[b:a:-1] should be reversed(s[a:b]), which is what
> many expect. It is not because the definition is given in terms of
> the translation into indexes and blindly applied to the case of
> negative strides without the needed adjustment. I consider this a
> design mistake, at least for many uses. (Extended slices, if not
> extended slicing, were added for numerical Python and they may have
> wanted the current definition for negative strides.)
I agree that this is a design mistake. Personnaly I find it horrible
that in the following expression: L[a:b:-1], it is impossible to
give a numeric value to b, that will include L[0] into the reversed
slice. It is the reason why I avoid reversed slices as much as
possible.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Re: add bitbucket repo url to install_requires
On 05/10/2010 12:43, Julian wrote: I'm developing a django app which depends on an app in a private bitbucket repository, for example ssh://[email protected]/username/my-django-app. is it possible to add this url to the list of install_requires in my setup.py? tried various possibilities, but none worked. That would be abhorent. Don't even try to do that. If the app has a setup.py, specify the name passed to setup() in setup.py in install_requires. Then you just need to make sure a distribution of the above is available when you want to install. What I would do: - clone the above repo - in your local clone do: python setup.py sdist - put the resulting .tgz somewhere safe and accessible - install using your package manager of choice and pass the "somewhere safe and accessible" location by way of --find-links or equivalent. cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Many newbie questions regarding python
Rogério Brito wrote: class C: f = 1 def g(self): return f I get an annoying message when I try to call the g method in an object of type C, telling me that there's no global symbol called f. If I make g return self.f instead, things work as expected, but the code loses some readability. Is there any way around this or is that simply "a matter of life"? class C: f =1 creates the 'C.f ' name. When 'f' is used in g, you'll get then an error. class C: f = 1 def g(self): return C.f is the obvious solution. However it can be slightly improved. f is a class attribute, meaning it's common to all instances of the C class. Thus g would be a class method, and is here declared liek a instance method (the instance being self). class C: f = 1 @classmethod def g(cls): return cls.f c1 = C() c2 = C() print c1.f, c2.f # f is not an attribute of c1 nor c2, thus the lookup will try in the class and find C.f 1 1 c1.f = 10 # this create the c1 instance attribute f != class attribute f c2.f = 20 # this create the c2 instance attribute f != class attribute f print c1.f, c2.f, c1.g(), c2.g(), C.f 10 20 1 1 1 Cheers, JM -- http://mail.python.org/mailman/listinfo/python-list
Re: frozendict (v0.1)
On 10/08/2010 02:23 AM, kj wrote:
I imagine that frozenset is better than sorted(tuple(...)) here,
but it's not obvious to me why.
dicts are unsorted. That means their item-order is undefined. So are sets.
If you want a hash that is independent from the order of items, you
could ensure the items are always in the same order when you do the
hashing; or you could use a hashing algorithm that ignore item order.
As creating a `frozenset` is probably more efficient than sorting, that
is the preferred solution.
Here's my implementation suggestion:
class frozendict(dict):
def _immutable_error(self, *args, **kwargs):
raise TypeError("%r object is immutable" % self.__class__.__name__)
__setitem__ = __delitem__ = clear = pop \
= popitem = setdefault = update = _immutable_error
def __hash__(self):
return hash(frozenset(self.iteritems()))
Only 9 lines :-)
Jonas
--
http://mail.python.org/mailman/listinfo/python-list
Re: frozendict (v0.1)
In <[email protected]> Steven D'Aprano writes: >On Fri, 08 Oct 2010 00:23:30 +, kj wrote: >Because it's always better to use a well-written, fast, efficient, >correct, well-tested wheel than to invent your own slow, incorrect >wheel :) IOW, "don't you worry your little head about why." -- http://mail.python.org/mailman/listinfo/python-list
Re: Many newbie questions regarding python
"Rogério Brito" wrote in message news:[email protected]... My first try to write it in Python was something like this: v = [] for i in range(20): v[i] = 0 Unfortunately, this doesn't work, as I get an index out of bounds when trying to index the v list. Python can't grow a list by assigning to out-of-bound elements (although, being the language it is, there is probably a way of achieving that by redefining how [] works...) What is the Pythonic way of writing code like this? So far, I have found many v = [0 for i in range(20)] v = [0] * 20 v = [] for i in range(20): v.append(0) What should I prefer? Any other alternative? v=[0,0,0,0,0, 0,0,0,0,0, 0,0,0,0,0, 0,0,0,0,0] will also work. But none of these appeal too much. I would probably do: def newlist(length,init=0): return [init]*length ... v=newlist(1000) (with the proviso that someone mentioned when the init value is complex: you might not get unique copies of each). If possible, I would like to simply declare the list and fill it latter in my program, as lazily as possible (this happens notoriously when one is using a technique of programming called dynamic programming where initializing all positions of a table may take too much time in comparison to the filling of the array). A sparse array? Even if an array could be constructed by assigning to arbitrary elements, the gaps created would still need filling in with None or Unassigned. 2 - If I declare a class with some member variables, is is strictly necessary This is where I bail out... -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: frozendict (v0.1)
In <[email protected]> Arnaud Delobelle writes: >E.g., try with {1:'a', 1j:'b'} I see. Thanks for this clarification. I learned a lot from it. I guess that frozenset must have some way of canonicalizing the order of its elements that is dependent on their Python values but not on their comparability. My first thought was that they are ordered according to their hash values, but this theory doesn't hold: >>> abc = ('a', 'b', 'c') >>> sorted(map(hash, abc)) [-468864544, -340864157, -212863774] >>> map(hash, frozenset(abc)) [-468864544, -212863774, -340864157] I.e. the ordering of the elements in the frozenset does not correspond to the ordering of their hashes in either direction. Hmmm. I tried to understand this by looking at the C source but I gave up after 10 fruitless minutes. (This has been invariably the outcome of all my attempts at finding my way through the Python C source.) I guess the take-home message is that frozenset is a more general way to canonicalize an iterable object than sorting, even though the reasons for this still remain a mystery to me... Then again, just looking at the voodoo that goes into algorithms for computing hashes fills me with despair. As much as I dislike it, sooner or later I'll have to go on faith. ~kj -- http://mail.python.org/mailman/listinfo/python-list
Re: harmful str(bytes)
Arnaud Delobelle writes: >Hallvard B Furuseth writes: >> I've been playing a bit with Python3.2a2, and frankly its charset >> handling looks _less_ safe than in Python 2. >> (...) >> With 2. conversion Unicode <-> string the equivalent operation did >> not silently produce garbage: it raised UnicodeError instead. With old >> raw Python strings that was not a problem in applications which did not >> need to convert any charsets, with python3 they can break. >> >> I really wish bytes.__str__ would at least by default fail. > > I think you misunderstand the purpose of str(). It is to provide a > (unicode) string representation of an object and has nothing to do with > converting it to unicode: That's not the point - the point is that for 2.* code which _uses_ str vs unicode, the equivalent 3.* code uses str vs bytes. Yet not the same way - a 2.* 'str' will sometimes be 3.* bytes, sometime str. So upgraded old code will have to expect both str and bytes. In 2.*, str<->unicode conversion failed or produced the equivalent character/byte data. Yes, there could be charset problems if the defaults were set up wrong, but that's a smaller problem than in 3.*. In 3.*, the bytes->str conversion always _silently_ produces garbage. And lots of code use both, and need to convert back and forth. In particular code 3.* code converted from 2.*, or using modules converted from 2.*. There's a lot of such code, and will be for a long time. -- Hallvard -- http://mail.python.org/mailman/listinfo/python-list
Re: mantissa and exponent in base 10
Jason Swails wrote:
>> s = ('%%%ig' % sigfigs) % n # double-% cancels the %
Thanks! I see that the parenthesis can be dropped, too:
>>> '%%.%ig' % 3 % 4.23456e-5
'4.23e-05'
/c
--
http://mail.python.org/mailman/listinfo/python-list
Re: harmful str(bytes)
Antoine Pitrou writes:
>Hallvard B Furuseth wrote:
>> The offender is bytes.__str__: str(b'foo') == "b'foo'".
>> It's often not clear from looking at a piece of code whether
>> some data is treated as strings or bytes, particularly when
>> translating from old code. Which means one cannot see from
>> context if str(s) or "%s" % s will produce garbage.
>
> This probably comes from overuse of str(s) and "%s". They can be useful
> to produce human-readable messages, but you shouldn't have to use them
> very often.
Maybe Python 3 has something better, but they could be hard to avoid in
Python 2. And certainly our site has plenty of code using them, whether
we should have avoided them or not.
>> I really wish bytes.__str__ would at least by default fail.
>
> Actually, the implicit contract of __str__ is that it never fails, so
> that everything can be printed out (for debugging purposes, etc.).
Nope:
$ python2 -c 'str(u"\u1000")'
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\u1000' in position
0: ordinal not in range(128)
And the equivalent:
$ python2 -c 'unicode("\xA0")'
Traceback (most recent call last):
File "", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa0 in position 0: ordinal
not in range(128)
In Python 2, these two UnicodeEncodeErrors made our data safe from code
which used str and unicode objects without checking too carefully which
was which. Code which sort the types out carefully enough would fail.
In Python 3, that safety only exists for bytes(str), not str(bytes).
--
Hallvard
--
http://mail.python.org/mailman/listinfo/python-list
Re: frozendict (v0.1)
On 10/08/2010 03:27 PM, kj wrote:
I tried to understand this by looking at the C source but I gave
up after 10 fruitless minutes. (This has been invariably the
outcome of all my attempts at finding my way through the Python C
source.)
It's not you. CPython's code is ... [censored]
Anyway, you don't even need to read C code to understand how sets are
implemented.
There is a (now deprecated) Python module, Libs/set.py, that has
implementations for `Set` and `ImmutableSet` (nowadays `set` and
`frozenset`).
The implementation strategy you can see there is quite simple. The code
uses dictionary keys to store the set items and "ignores" the dictionary
values, so that `.add(value)` is implemented as `._dict[value] =
some_value_nobody_cares_about`.
Here comes a very limited example set implementation using a dict:
class PrimitiveSet(object):
def __init__(self):
self._dict = {}
def add(self, value):
self._dict[value] = True
def __contains__(self, value):
return value in self._dict
def __repr__(self):
return 'PrimitiveSet(%r)' % self._dict.keys()
>>> s = PrimitiveSet()
>>> 'hello' in s
False
>>> s.add('hello')
>>> 'hello' in s
True
>>> s
PrimitiveSet(['hello'])
>>> s.add(tuple(xrange(10)))
>>> s
PrimitiveSet([(0, 1, 2, 3, 4, 5, 6, 7, 8, 9), 'hello'])
>>> s.add(xrange(5))
>>> s
PrimitiveSet([(0, 1, 2, 3, 4, 5, 6, 7, 8, 9), xrange(5), 'hello'])
This has a few implications for sets:
* dict keys are unordered/sorted. so are sets.
* dict keys are unique. same for set values.
* dict keys have to be hashable (immutable). same for sets values.
So far our implementation is not hashable, and we need a custom
implementation for __hash__ (because dicts aren't hashable, so we cannot
re-use dictionary methods).
There is one requirement for set hashes: they have to be independent of
the item order (there *is* an order in memory of course, and it may vary
depending on the order assignments to our dict are done).
Here is an extract from the Python set implementation,
`BaseSet._compute_hash`:
def _compute_hash(self):
# Calculate hash code for a set by xor'ing the hash codes of
# the elements. This ensures that the hash code does not depend
# on the order in which elements are added to the set. [...]
result = 0
for elt in self:
result ^= hash(elt)
return result
Hope this helps :-)
Jonas
--
http://mail.python.org/mailman/listinfo/python-list
Re: frozendict (v0.1)
In kj writes:
>At any rate, using your [i.e. Arnaud's] suggestions in this and
>your other post, the current implementation of frozendict stands
>at:
>class frozendict(dict):
>for method in ('__delitem__ __setitem__ clear pop popitem setdefault '
> 'update').split():
>exec """
>def %s(self, *a, **k):
>cn = self.__class__.__name__
>raise TypeError("'%%s' object is not mutable" %% cn)
>""" % method
>def __hash__(self):
>return hash(frozenset(self.items()))
>...which is a lot nicer!
As a side comment on my own post, this is the second time in less
than a week that I find myself having to resort to exec'ing some
code generated from a template. This one is worse, because there's
nothing runtime-dependent about the code being exec'd. It sticks
in my craw somehow. It just doesn't seem quite right that at the
time of doing something as bread-and-butter as implementing a
subclass, one has to choose between explicitly writing a whole
bunch of identical methods, and exec-based hacks like what I'm
doing above. There's got to be a "better" to tell Python: "override
all these superclass methods with this one."
Or maybe the problem here is that, in a perfect world, frozendict
would be in the standard library, as a superclass of dict lacking
all of dict's destructive methods. :)
~kj
--
http://mail.python.org/mailman/listinfo/python-list
Re: frozendict (v0.1)
In "Jonas H."
writes:
>On 10/08/2010 02:23 AM, kj wrote:
>Here's my implementation suggestion:
>class frozendict(dict):
> def _immutable_error(self, *args, **kwargs):
> raise TypeError("%r object is immutable" % self.__class__.__name__)
> __setitem__ = __delitem__ = clear = pop \
> = popitem = setdefault = update = _immutable_error
> def __hash__(self):
> return hash(frozenset(self.iteritems()))
>Only 9 lines :-)
Thanks, you just answered the question I just posted, while I was
still writing it!
~kj
--
http://mail.python.org/mailman/listinfo/python-list
Re: frozendict (v0.1)
In "Jonas H." writes: >Hope this helps :-) It did! Thanks! For one thing now I see that I was barking up the wrong tree in focusing on a canonical order, when, as the code you posted shows, it is actually not required for hashing. In fact, I'd come to the conclusion that frozensets had a consistent order (i.e. frozensets that were equal according to '==' would be iterated over in the same order), but now I'm not sure that this is the case. (Granted, semantically, there's nothing in the definition of a frozenset that would imply a consistent iteration order.) Thanks again! ~kj -- http://mail.python.org/mailman/listinfo/python-list
Help with pointers when calling from python to C
Hi.
This is kind of a cross-product question, having to do with accessibility
on Linux using ATK (AT-SPI).
However, I think it really boils down to a python question: "How do I pass
an integer by reference to a C function?"
I am using Accerciser (http://live.gnome.org/Accerciser), an accessibility
testing tool that has an ipython console.
It uses pyatspi to interact with AT-SPI through pyORBit.
I need to test my handling of
atk_editable_text_insert_text(AtkEditableText *text, const gchar *string,
gint length, gint *position).
In the example below, the variable 'acc' has been bound (by Accerciser) to
an accessible object that implements the AtkEditableText interface.
The problem is that the pesky "position" parameter wants a pointer to an
integer.
I have tried all sorts of ways to get Accerciser's iPython console to
accept the last parameter, but I always get: "TypeError: could not marshal
arg 'position'."
Has anyone done this? If so, then how is it done?
Here's a sample of the things I tried:
In [1]: t=acc.queryEditableText()
In [2]: t.getText(0,45)
Out[2]: 'The quick brown fox jumps over the lazy dog.\n'
In [3]: t.deleteText(10,15)
Out[3]: True
In [4]: t.getText(0,40)
Out[4]: 'The quick fox jumps over the lazy dog.\n'
In [5]: pos=10
In [6]: t.insertText("brown",5,pos)
---
TypeError Traceback (most recent call
last)
/usr/lib/python2.6/dist-packages/pyatspi/__init__.pyc in ()
> 1
2
3
4
5
/usr/lib/python2.6/dist-packages/pyatspi/accessible.pyc in _inner(self,
*args, **kwargs)
230 try:
231 # try calling the original func
--> 232 return func(self, *args, **kwargs)
233 except ORBit.CORBA.NO_IMPLEMENT, e:
234 # raise Python exception
TypeError: could not marshal arg 'position'
In [7]: t.insertText("brown",5,id(pos))
---
TypeError Traceback (most recent call
last)
/usr/lib/python2.6/dist-packages/pyatspi/__init__.pyc in ()
> 1
2
3
4
5
/usr/lib/python2.6/dist-packages/pyatspi/accessible.pyc in _inner(self,
*args, **kwargs)
230 try:
231 # try calling the original func
--> 232 return func(self, *args, **kwargs)
233 except ORBit.CORBA.NO_IMPLEMENT, e:
234 # raise Python exception
TypeError: could not marshal arg 'position'
In [8]: pos=[10]
In [9]: t.insertText("brown",5,pos)
---
TypeError Traceback (most recent call
last)
/usr/lib/python2.6/dist-packages/pyatspi/__init__.pyc in ()
> 1
2
3
4
5
/usr/lib/python2.6/dist-packages/pyatspi/accessible.pyc in _inner(self,
*args, **kwargs)
230 try:
231 # try calling the original func
--> 232 return func(self, *args, **kwargs)
233 except ORBit.CORBA.NO_IMPLEMENT, e:
234 # raise Python exception
TypeError: could not marshal arg 'position'
In [7]: pos=array([10])
---
NameError Traceback (most recent call
last)
/usr/lib/python2.6/dist-packages/pyatspi/__init__.pyc in ()
> 1
2
3
4
5
NameError: name 'array' is not defined
Thanks,
Carolyn--
http://mail.python.org/mailman/listinfo/python-list
Re: Help with pointers when calling from python to C
On 10/08/2010 05:23 PM, Carolyn MacLeod wrote: "How do I pass an integer by reference to a C function?" That's impossible in pure Python. The only thing I can think of is a wrapper in C. -- http://mail.python.org/mailman/listinfo/python-list
Re: Many newbie questions regarding python
On 2010-10-08, BartC wrote: > "Rogério Brito" wrote in message > news:[email protected]... >> If possible, I would like to simply declare the list and fill it latter in >> my >> program, as lazily as possible (this happens notoriously when one is using >> a >> technique of programming called dynamic programming where initializing all >> positions of a table may take too much time in comparison to the filling >> of the >> array). > > A sparse array? Even if an array could be constructed by assigning to I agree, what the OP seems to want (whether he actually needs it or not) is a sparse array. > A sparse array? Even if an array could be constructed by assigning to > arbitrary elements, the gaps created would still need filling in with None > or Unassigned. That is only true when attempting to address elements based on their position rather then something like rank. You could create an object with some kind of index attribute that you could search for built in. When you needed to access the element, you simply walked the list until you find the matching identifier. The spaces no longer need filling since you are not matching based on absolute position in the list. This is of course inefficient for large lists, and while there are several methods of making this method more efficient (indexing, skip linking, b-tree, etc), you can get what you want very efficiently most of the time by simply using the built in dictionary with integer keys instead of a list. -- http://mail.python.org/mailman/listinfo/python-list
Re: Eclipse/PyDev - BOM Lexical Error
Lawrence D'Oliveiro wrote: In message <[email protected]>, Diez B. Roggisch wrote: Lawrence D'Oliveiro writes: In message <[email protected]>, Diez B. Roggisch wrote: Lawrence D'Oliveiro writes: What exactly is the point of a BOM in a UTF-8-encoded file? It's a marker like the "coding: utf-8" in python-files. It tells the software aware of it that the content is UTF-8. But if the software is aware of it, then why does it need to be told? Let me rephrase: windows editors such as notepad recognize the BOM, and then assume (hopefully rightfully so) that the rest of the file is text in utf-8 encoding. But they can only recognize it as a BOM if they assume UTF-8 encoding to begin with. Otherwise it could be interpreted as some other coding. Not so. The first three bytes are the flag. For example, in a .dbf file, the first byte determines what type of dbf the file is: \x03 = dBase III, \x83 = dBase III with memos, etc. More checking should naturally be done to ensure the rest of the fields make sense for the dbf type specified. MS decided that if the first three bytes = \xEF \xBB \xBF then it's a UTF-8 file, and if it is not, don't open it with an MS product. Likewise, MS will add those bytes to any UTF-8 file it saves. Naturally, this causes problems for non-MS usages, but anybody who's had to work with both MS and non-MS platforms/products/methodologies knows that MS does not play well with others. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Many newbie questions regarding python
On 2010-10-07, Rog??rio Brito wrote: > If possible, I would like to simply declare the list and fill it > latter in my program, as lazily as possible (this happens notoriously > when one is using a technique of programming called dynamic > programming where initializing all positions of a table may take too > much time in comparison to the filling of the array). At first you say you want a list, later you say you want an array. They're two different things. Arrays are variable-length and can be heterogeneous. If what you really want is a fixed-length, homogeneous array, then use an array instead of a list: http://docs.python.org/library/array.html > If I declare a class with some member variables, is is strictly > necessary for me to qualify those members in a method in that class? Yes. > I get an annoying message when I try to call the g method in an > object of type C, telling me that there's no global symbol called f. > If I make g return self.f instead, things work as expected, but the > code loses some readability. That's a matter of opinion. Some of us _like_ self.f since it explicitly shows the reader that f isn't a global or local but a class or instance variable. Any time you make the reader/maintainer guess what something is, that's a bug waiting to happen. > Is there any way around this or is that simply "a matter of life"? Well, that's how Python works. I won't comment on "life". -- Grant Edwards grant.b.edwardsYow! I feel like a wet at parking meter on Darvon! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: frozendict (v0.1)
On Fri, 08 Oct 2010 12:10:50 +, kj wrote: > In <[email protected]> Steven D'Aprano > writes: > >>On Fri, 08 Oct 2010 00:23:30 +, kj wrote: > >>Because it's always better to use a well-written, fast, efficient, >>correct, well-tested wheel than to invent your own slow, incorrect wheel >>:) > > IOW, "don't you worry your little head about why." Shame on you for deleting the context of my answer. You said: "I imagine that frozenset is better than sorted(tuple(...)) here, but it's not obvious to me why." Because frozenset already works. Because somebody else has done the work, and debugged it, and tested it, and profiled it, and optimized it, and ensured that it is correct and fast. That saves you a lot of effort, and frees you from having to duplicate the same functionality, and debugging it, testing it, profiling it, and optimizing it. Every line of code that you can avoid writing is a win. If you're a carpenter, it is better to buy a hammer than it is to go out and dig up your own iron ore, smelt the metal, and forge it into a hammer: unless you're in the business of making hammers, you've got better things to do with your time. And if you're a programmer, you've got better things to do than write a slower, buggier version of code that already exists. If you want to know *what* the frozenset does that is better, then go read the source code. For all I know you might discover that it does the same thing as your code. It's *still* better to use frozenset, simply because it already exists. Unless you profile your code and discover that frozenset is too slow and you can do better, there is no reason not to use it, and many reasons to use it. This has nothing to do with "your little head", but about code reuse. Almost the entire history of programming, from the invention of sub- routines to the open source movement, is about code reuse. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Many newbie questions regarding python
On 2010-10-08, Grant Edwards wrote: > On 2010-10-07, Rog??rio Brito wrote: > >> If possible, I would like to simply declare the list and fill it >> latter in my program, as lazily as possible (this happens notoriously >> when one is using a technique of programming called dynamic >> programming where initializing all positions of a table may take too >> much time in comparison to the filling of the array). > > At first you say you want a list, later you say you want an array. > They're two different things. Arrays are variable-length and can be > heterogeneous. I meant _Lists_ are fixed-length and homogeneous > If what you really want is a fixed-length, homogeneous array, then > use an array instead of a list: > > http://docs.python.org/library/array.html Actually, that's not the right link either. I was thinking more of NumPy arrays, where you can create an arbitrary sized homogeneous array of a desired type (either uninitialized or filled with zeros or ones): http://www.scipy.org/Tentative_NumPy_Tutorial#head-d3f8e5fe9b903f3c3b2a5c0dfceb60d71602cf93 If you're crunching so many numbers that initializing a list is a problem, then you probably ought to be using NumPy. -- Grant Edwards grant.b.edwardsYow! for ARTIFICIAL at FLAVORING!! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Many newbie questions regarding python
On 2010-10-08, Grant Edwards wrote: > On 2010-10-08, Grant Edwards wrote: >> On 2010-10-07, Rog??rio Brito wrote: >> >>> If possible, I would like to simply declare the list and fill it >>> latter in my program, as lazily as possible (this happens notoriously >>> when one is using a technique of programming called dynamic >>> programming where initializing all positions of a table may take too >>> much time in comparison to the filling of the array). >> >> At first you say you want a list, later you say you want an array. >> They're two different things. Arrays are variable-length and can be >> heterogeneous. > > I meant _Lists_ are fixed-length and homogeneous Damn. I should give up and go golfing. _Lists_ are variable-length and can be heterogenous. _Arrays_ are homogenous and sort-of fixed length. > [...] I was thinking more of NumPy arrays, where you can create an > arbitrary sized homogeneous array of a desired type (either > uninitialized or filled with zeros or ones): > > > http://www.scipy.org/Tentative_NumPy_Tutorial#head-d3f8e5fe9b903f3c3b2a5c0dfceb60d71602cf93 > > If you're crunching so many numbers that initializing a list is > a problem, then you probably ought to be using NumPy. -- Grant Edwards grant.b.edwardsYow! I'm shaving!! at I'M SHAVING!! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: frozendict (v0.1)
On Fri, 08 Oct 2010 14:00:17 +, kj wrote:
> In kj writes:
>
>>At any rate, using your [i.e. Arnaud's] suggestions in this and your
>>other post, the current implementation of frozendict stands at:
>
>>class frozendict(dict):
>>for method in ('__delitem__ __setitem__ clear pop popitem'
>> 'setdefault update').split():
>>exec """
>>def %s(self, *a, **k):
>>cn = self.__class__.__name__
>>raise TypeError("'%%s' object is not mutable" %% cn)
>>""" % method
>
>>def __hash__(self):
>>return hash(frozenset(self.items()))
>
>>...which is a lot nicer!
>
> As a side comment on my own post, this is the second time in less than a
> week that I find myself having to resort to exec'ing some code generated
> from a template. This one is worse, because there's nothing
> runtime-dependent about the code being exec'd.
Er, *all* Python classes are created at runtime. The class statement is
executed at runtime, not compile time. Not that it really matters.
But in any case, it's easy enough to avoid exec with a factory function.
The following is untested, but should work:
def no_mutate_factory(name):
def inner(self, *args, **kwargs):
cn = self.__class__.__name__
raise TypeError('%s instance is not mutable' % cn)
inner.__name__ = name
return inner
class FrozenDict(dict):
update = no_mutate_factory('update')
clear = no_mutate_factory('clear')
# ...
It's a bit messy to have to list the name of the method twice. But you
can inject the appropriate methods into the class by adding them from
outside the class block:
class FrozenDict(dict):
pass
for name in 'update clear'.split() # and the others
setattr(FrozenDict, name, no_mutate_factory(name))
del name # Avoid namespace pollution, if you care.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Fri, 08 Oct 2010 10:21:16 +0200, Antoon Pardon wrote: > Personnaly I find it horrible > that in the following expression: L[a:b:-1], it is impossible to give a > numeric value to b, that will include L[0] into the reversed slice. >>> L = [1, 2, 3, 4, 5] >>> L[5:-6:-1] [5, 4, 3, 2, 1] -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: harmful str(bytes)
On Fri, 08 Oct 2010 15:31:27 +0200, Hallvard B Furuseth wrote:
> Arnaud Delobelle writes:
>>Hallvard B Furuseth writes:
>>> I've been playing a bit with Python3.2a2, and frankly its charset
>>> handling looks _less_ safe than in Python 2. (...)
>>> With 2. conversion Unicode <-> string the equivalent operation
>>> did not silently produce garbage: it raised UnicodeError instead.
>>> With old raw Python strings that was not a problem in applications
>>> which did not need to convert any charsets, with python3 they can
>>> break.
>>>
>>> I really wish bytes.__str__ would at least by default fail.
>>
>> I think you misunderstand the purpose of str(). It is to provide a
>> (unicode) string representation of an object and has nothing to do with
>> converting it to unicode:
>
> That's not the point - the point is that for 2.* code which _uses_ str
> vs unicode, the equivalent 3.* code uses str vs bytes. Yet not the same
> way - a 2.* 'str' will sometimes be 3.* bytes, sometime str. So
> upgraded old code will have to expect both str and bytes.
I'm sorry, this makes no sense to me. I've read it repeatedly, and I
still don't understand what you're trying to say.
> In 2.*, str<->unicode conversion failed or produced the equivalent
> character/byte data. Yes, there could be charset problems if the
> defaults were set up wrong, but that's a smaller problem than in 3.*. In
> 3.*, the bytes->str conversion always _silently_ produces garbage.
So you say, but I don't see it. Why is this garbage?
>>> b = b'abc\xff'
>>> str(b)
"b'abc\\xff'"
That's what I would expect from the str() function called with a bytes
argument. Since decoding bytes requires a codec, which you haven't given,
it can only return a string representation of the bytes.
If you want to decode bytes into a string, you need to specify a codec:
>>> >>> str(b, 'latin-1')
'abcÿ'
>>> b.decode('latin-1')
'abcÿ'
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Many newbie questions regarding python
On 10/8/2010 10:15 AM Grant Edwards said... Damn. I should give up and go golfing. +1 QOTW Emile -- http://mail.python.org/mailman/listinfo/python-list
PYTHON
PLEASE LEARN ME PYTHON -- http://mail.python.org/mailman/listinfo/python-list
Re: PYTHON
On 2010-10-08, k.. wrote: > PLEASE LEARN ME PYTHON Done! Please be sure to drop by sometimes to let us know how it's going, now that we've learned you Python. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / [email protected] http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: if the else short form
On Oct 7, 9:23 am, Lawrence D'Oliveiro wrote:
> x = {1 : "One", 2 : "Two", 3 : "Three"}.get(i, "None Of The Above")
More like:
x = {1:lambda:"One", 2:lambda:"Two", 3:lambda:"Three"}.get(i,
lambda:"None Of The Above")()
i.e. deferred evaluation of selected case.
In Algol68 this would be:
x:=(i|"One","Two","Three"|"None Of The Above")
N
--
To download Linux's Algol68 Compiler, Interpreter & Runtime:
* http://sourceforge.net/projects/algol68/files
--
http://mail.python.org/mailman/listinfo/python-list
Re: Many newbie questions regarding python
On Oct 7, 6:10 pm, Rogério Brito wrote:
> Hi there.
>
> I am used to some languages like C, but I am just a complete newbie with
> Python
> and, while writing some small snippets, I had encountered some problems, with
> which I would sincerely appreciate any help, since I appreciate this language
> to
> write my "running pseudocode in" and I am seriously thinking of using it to
> teach some algorithms classes.
>
> 1 - The first issue that I am having is that I don't seem to be able to, say,
> use something that would be common for people writing programs in C: defining
> a
> one-dimensional vector and only initializing it when needed.
>
> For instance, in C, I would write something like:
>
> int v[20];
> for (i = 0; i < 20; i++)
> v[i] = 0;
>
> Note that I only define the vector v (and its size) at the beginning but
> initialize it latter during the code per-se.
>
> My first try to write it in Python was something like this:
>
> v = []
> for i in range(20):
> v[i] = 0
>
> Unfortunately, this doesn't work, as I get an index out of bounds when trying
> to
> index the v list. Of course, the main difference between the two snippets is
> that, in C, I declared v to have 20 positions, while in python I initialized
> it
> to be the empty list and, indeed, it has an empty set of indexes.
>
> What is the Pythonic way of writing code like this? So far, I have found many
> alternatives and I would like to write code that others in the Python
> community
> would find natural to read. Some of the things that crossed my mind:
>
> v = [0 for i in range(20)]
>
> v = [0] * 20
>
> v = []
> for i in range(20): v.append(0)
>
> What should I prefer? Any other alternative?
>
> If possible, I would like to simply declare the list and fill it latter in my
> program, as lazily as possible (this happens notoriously when one is using a
> technique of programming called dynamic programming where initializing all
> positions of a table may take too much time in comparison to the filling of
> the
> array).
>
> 2 - If I declare a class with some member variables, is is strictly necessary
> for me to qualify those members in a method in that class? For instance, if I
> define:
>
> class C:
> f = 1
> def g(self):
> return f
>
> I get an annoying message when I try to call the g method in an object of type
> C, telling me that there's no global symbol called f. If I make g return
> self.f
> instead, things work as expected, but the code loses some readability.
>
> Is there any way around this or is that simply "a matter of life"?
>
> I have some other questions, but I will save them for latter.
>
> Please, keep in mind that I am a newbie in Python. Despite that, I am enjoying
> the little that I know.
>
> Thank you very much in advance,
>
> --
> Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key
> 4096R/BCFChttp://rb.doesntexist.org: Packages for LaTeX :
> algorithms.berlios.de
> DebianQA:http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
How about:
v = [None] * 20
That way, you're not initializing with an artifical value like 0.
--
http://mail.python.org/mailman/listinfo/python-list
Re: if the else short form
On Oct 7, 10:36 am, "BartC" wrote:
> i=16
> x = {1 : fna(), 2 : fnb(), 3 : fnc()}.get(i, "None Of The Above")
> print x
>
> Other than efficiency concerns, sometimes you don't want the extra
> side-effects.
>
> Probably there are workarounds here too, but I suspect the syntax won't be
> quite as pert as the Algol68-style example:
>
> x = (i | "Zero", "One", "Two" | "None of the above") # 0-based
/* ¢ Algol68 case clause is 1-based. ¢ */
However Algol68's CASE ~ IN ~,~,~,~ OUT ~ ESAC clause does mean that
the case items of the clause are not evaluated unless selected. Here
are some comparisons with python:
$ cat py_case.py
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# This procedure evaluates all the months lengths _before_ building
the dict.
# In that case of month length, they are constants.
def days_in_month0(year, month):
return {1:31,
2:{True:29,False:28}[year%4==0 and year%100!=0 or year%400==0],
3:31,4:30,5:31,6:30,7:31,8:31,9:30,10:31,11:30,12:31
}.get(month,None)
# This procedure is closer - in behaviour - to that of the algol68
case clause.
# Keypoint being that individual month length code is not evaluated
unless called()
def days_in_month(year, month):
return {1:lambda:31,
2:lambda:{True:lambda:29,False:lambda:28}[year%4==0 and year%100!
=0 or year%400==0](),
3:lambda:31,4:lambda:30,5:lambda:31,6:lambda:30,7:lambda:
31,8:lambda:31,9:lambda:30,10:lambda:31,11:lambda:30,12:lambda:31
}.get(month,"None of the above")()
for year in 1899,1900,1901,1999,2000,2001:
print "%4d=%2d"%(year,days_in_month0(year, 2)),
"""
Compare with Algol 68:
Brief choice clause example:
PROC days in month = (INT year, month)UNION(INT,STRING):
(month|31,
(year%×4=0 ∧ year%×100≠0 ∨ year%×400=0|29|28),
31,30,31,30,31,31,30,31,30,31
|"None of the above" # or EMPTY #
);
BOLD choice clause example:
PROC days in month = (INT year, month)UNION(INT,STRING):
CASE month IN 31,
IF year MOD 4 EQ 0 AND year MOD 100 NE 0 OR year MOD 400 EQ 0 THEN
29 ELSE 28 FI,
31,30,31,30,31,31,30,31,30,31
OUT "None of the above" # or EMPTY #
ESAC;
[]INT years = (1899,1900,1901,1999,2000,2001);
FOR key TO UPB years DO INT year=years[key];
printf(($4d,"="2d" "$, year, days in month(year, 2)))
OD
"""
$ python py_case.py
1899=28 1900=28 1901=28 1999=28 2000=29 2001=28
There are also the compound IF and CASE conditional clauses:
IF condition1 THEN statements ELIF condition2 THEN statements [ ELSE
statements ] FI
"brief" form if IF clause: ( condition1 | statements |: condition2 |
statements | statements )
CASE switch1 IN statements, statements,... OUSE switch2 IN
statements, statements,... [ OUT statements ] ESAC
"brief" form of CASE statement: ( switch1 |
statements,statements,... |: switch2 | statements,statements,... |
statements )
Enjoy
NevilleDNZ
--
To download Linux's Algol68 Compiler, Interpreter & Runtime:
* http://sourceforge.net/projects/algol68/files
--
http://mail.python.org/mailman/listinfo/python-list
open file on mac
hi, sorry if it is a stupid qustio,but i cannot figure out where's the
problem.
i've a simpleModule:
class Starter:
def init(self,num):
print "hithere!"
print "the answer is ",num
import sys,os
print "path:",sys.path
try:
#f = open("/Users/lguerrasio/myfold/initfile.py",'r')
f = open("initfile.py",'r')
f.close()
print "huurray!"
except IOError:
print "The file does not exist, exiting gracefully"
print "This line will always print"
The module is located in the same folder of initfile.py
now,from terminal I import sys and add to the path the folder /Users/
lguerrasio/myfold; the I import the module and execute
simpleModule.Starter().init(48)
on mac I get an error if i do not give the full path of initfile.py
(commented out in the code above);
on windows i did not have this problem.
Am I missing anything?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Many newbie questions regarding python
On Oct 8, 10:27 am, Steven D'Aprano wrote: > > v = [0 for i in range(20)] > > Absolutely not. Such a code snippet is very common, in fact I've done it > myself, but it is a "hammer solution" -- to a small boy with a hammer, > everything looks like a nail that needs hammering. Writing such a list > comprehension is a "list comp solution". > > > v = [0] * 20 > > Yes, this is the solution. But the list comp version will work as expected for mutable types, whereas the 'solution' only works for immutable types. If anything, I feel like the list comp version is the correct solution because of its reliability, whereas the multiplication form feels like either a lucky naive approach or relies on the reader to know the type of the initialising value and its mutability. -- http://mail.python.org/mailman/listinfo/python-list
Re: SysLogHandler message formatting
On Oct 7, 6:18 am, Vinay Sajip wrote: > Thanks for the detailed report. I tried posting a response a couple of times, > but Google appears to have swallowed it ... trying again. Sorry if it results > in > multiple responses. I tried to respond yesterday, but I also noticed this probelm. > The SysLogHandler aims to work within RFC 5424, though that does provide for > some flexibility in message formats. The SysLogHandler sends > formatted > message, as you've observed, with the "formatted message" part encoded in > UTF-8 > with a prepended BOM if it's Unicode. I started to read RFC 5424 yesterday before posting this, but it seemed to describe a much more complex message format than SysLogHandler was producing, so I wasn't sure if that was the reference or not. I may go back and read it completely, now that I know, though. > The existing SysLogHandler code seems to work OK with syslog, syslog-ng and > rsyslog > I agree with this, so I would normally assume that Metalog is the problem and simply stop using it. Unfortunately, I have several systems that use Metalog, and I don't want to introduce any inconsistencies by having one use something else. Switching them all would also be a hassle. > - perhaps these are more forgiving than Metalog in the way they parse > messages, or perhaps it's a Metalog configuration issue. I'd try posting this > issue to the Metalog forum / mailing list to see what feedback they can give. > I will do that; I just wanted to see what the Python stance was first. I will keep you apprised of anything determined through that route. > If you do think it's a bug in SysLogHandler then please create an issue on > bugs.python.org and assign it to me, so I can take a look at it After I communicate with the Metalog community, I will definitely file an issue if necessary. I didn't want to jump the gun, though. > I think using an appropriate Formatter will ensure interoperability in any > particular scenario. I don't especially want to hard-code any format into > SysLogHandler, since a Formatter can be used to set the format flexibly. I think the only problem with doing it that way is that I wasn't initially aware that using a Formatter affected how the message is sent to Syslog, but assumed it only modified the visible portion. I will admit that, until yesterday, I knew nothing of the syslog protocol. Perhaps the best solution would be to simply document the fact that adjusting the message format can affect how the message is parsed by the syslog daemon receiving it. Thank you for your feedback. -- http://mail.python.org/mailman/listinfo/python-list
google.com/trends
google.com/trends -- http://mail.python.org/mailman/listinfo/python-list
Re: Many newbie questions regarding python
On Oct 7, 7:10 pm, Rogério Brito wrote:
> Hi there.
>
> I am used to some languages like C, but I am just a complete newbie with
> Python
> and, while writing some small snippets, I had encountered some problems, with
> which I would sincerely appreciate any help, since I appreciate this language
> to
> write my "running pseudocode in" and I am seriously thinking of using it to
> teach some algorithms classes.
>
> 1 - The first issue that I am having is that I don't seem to be able to, say,
> use something that would be common for people writing programs in C: defining
> a
> one-dimensional vector and only initializing it when needed.
>
> For instance, in C, I would write something like:
>
> int v[20];
> for (i = 0; i < 20; i++)
> v[i] = 0;
>
> Note that I only define the vector v (and its size) at the beginning but
> initialize it latter during the code per-se.
>
> My first try to write it in Python was something like this:
>
> v = []
> for i in range(20):
> v[i] = 0
>
> Unfortunately, this doesn't work, as I get an index out of bounds when trying
> to
> index the v list. Of course, the main difference between the two snippets is
> that, in C, I declared v to have 20 positions, while in python I initialized
> it
> to be the empty list and, indeed, it has an empty set of indexes.
>
> What is the Pythonic way of writing code like this? So far, I have found many
> alternatives and I would like to write code that others in the Python
> community
> would find natural to read. Some of the things that crossed my mind:
>
> v = [0 for i in range(20)]
>
> v = [0] * 20
>
> v = []
> for i in range(20): v.append(0)
>
> What should I prefer? Any other alternative?
>
> If possible, I would like to simply declare the list and fill it latter in my
> program, as lazily as possible (this happens notoriously when one is using a
> technique of programming called dynamic programming where initializing all
> positions of a table may take too much time in comparison to the filling of
> the
> array).
Just to emphasize what Andreas said:
While
v = [0] * 20
is nice and good,
don't do this
v = [ [] ] * 20
or this
v = [ {} ] * 20
until you have played around with it on the interactive prompt to
understand how it works.
The difference of behavior of mutable vs immutable objects is one of
the main pitfalls for beginners in Python. Everything is very
consistent once you understand the assignment semantics, but it really
confuses people accustomed to other languages that work differently.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Simple database explorer
On Oct 7, 7:49 am, Lawrence D'Oliveiro wrote: > In message > <21c99273-ed58-4f93-b98a-d9292de5d...@k10g2000yqa.googlegroups.com>, dusans > wrote: > > > - all the others having ODBC drivers... > > ODBC seems to be something you use when you can’t use a proper database > driver. yes. first i have been mixing native and odbc drivers. Now i only use odbc. Odbc is not the best but its good enought for a sql explorer. Dont know how its on unix thou -- http://mail.python.org/mailman/listinfo/python-list
Re: pywebkit - python bindings for webkit DOM (alpha)
apologies for the 3 copies of the post: mail.python.org's SMTP service was offline yesterday. just a quick update: XMLHttpRequest support has been fixed today, and the correct version of libsoup discovered which actually works. that puts PythonWebkit into a "useful and useable" state, despite being only 15 days old. further development is still needed, but it's still pretty exciting to be back to where the original python webkit bindings code was, from 2008, minus the cruft from the intermediate glib/gobject layer, in such a short amount of time. l. -- http://mail.python.org/mailman/listinfo/python-list
HI... WE R HOT COUPLES AND SEARCHING FOR HOT MAN, WOMAN OR COUPLES FOR REAL FUN
HI... WE R HOT COUPLES AND SEARCHING FOR HOT MAN, WOMAN OR COUPLES FOR REAL FUN JUST CLICK... http://adultfriendfinder.com/go/page/reg_form_video_03?pid=g1250650-ppc http://adultfriendfinder.com/go/page/reg_form_video_03?pid=g1250650-ppc http://adultfriendfinder.com/go/page/reg_form_video_03?pid=g1250650-ppc -- http://mail.python.org/mailman/listinfo/python-list
Re: SysLogHandler message formatting
On Oct 7, 6:18 am, Vinay Sajip wrote: > Thanks for the detailed report. I tried posting a response a couple of times, > but Google appears to have swallowed it ... trying again. Sorry if it results > in > multiple responses. Hmm, I too seem to be experiencing this problem... > The SysLogHandler aims to work within RFC 5424, though that does provide for > some flexibility in message formats. The SysLogHandler sends > formatted > message, as you've observed, with the "formatted message" part encoded in > UTF-8 > with a prepended BOM if it's Unicode. I started to read RFC 5424 yesterday before posting this, but it seemed to describe a much more complex message format than SysLogHandler was producing, so I wasn't sure if that was the reference or not. I may go back and read it completely, now that I know, though. > The existing SysLogHandler code seems to work OK with syslog, syslog-ng and > rsyslog > I agree with this, so I would normally assume that Metalog is the problem and simply stop using it. Unfortunately, I have several systems that use Metalog, and I don't want to introduce any inconsistencies by having one use something else. Switching them all would also be a hassle. > - perhaps these are more forgiving than Metalog in the way they parse > messages, or perhaps it's a Metalog configuration issue. I'd try posting this > issue to the Metalog forum / mailing list to see what feedback they can give. > I will do that; I just wanted to see what the Python stance was first. I will keep you apprised of anything determined through that route. > If you do think it's a bug in SysLogHandler then please create an issue on > bugs.python.org and assign it to me, so I can take a look at it After I communicate with the Metalog community, I will definitely file an issue if necessary. I didn't want to jump the gun, though. > I think using an appropriate Formatter will ensure interoperability in any > particular scenario. I don't especially want to hard-code any format into > SysLogHandler, since a Formatter can be used to set the format flexibly. I think the only problem with doing it that way is that I wasn't initially aware that using a Formatter affected how the message is sent to Syslog, but assumed it only modified the visible portion. I will admit that, until yesterday, I knew nothing of the syslog protocol. Perhaps the best solution would be to simply document the fact that adjusting the message format can affect how the message is parsed by the syslog daemon receiving it. Thank you for your feedback. -- http://mail.python.org/mailman/listinfo/python-list
Sys.exit in secondary threads
I've noticed that there is nothing in python's documentation regarding the use of sys.exit(code) in a non-main thread. As far as I've seen, the behaviour in this case is to simply exit the thread, without caring about the return code. in the main thread however, the return code becomes the official return code of the whole process. Is that all we have to say about sys.exit() in a multithreaded program ? Or are there corner cases I've missed ? We'd better document this anyway. Regards, Pascal -- http://mail.python.org/mailman/listinfo/python-list
open file on mac
hallo, i'm sorry if the question is very stupid, but i cannot
understand what i'm doing wrong here.
i have this myModule.py
class Starter:
def init(self,num):
print "hithere!"
print "the answer is ",num
import sys,os
print "path:",sys.path
print "bye"
try:
##f = open("/Users/lguerrasio/_myfold/initfile.py",'r')
f = open("initfile.py",'r')
f.close()
print "huurray!"
except IOError:
print "The file does not exist, exiting gracefully"
print "This line will always print"
the module is in the same folder of initfile
from terminal, i import sys and add to the path /Users/lguerrasio/
_myfold/;
then i import the module and call
myModule.Starter().init(9)
now,the file will be opened only if i give the full path, not if i
give only the name of the file, although the folder is in the path.
what am I missing?
--
http://mail.python.org/mailman/listinfo/python-list
Re: ConFoo spam?
On Oct 7, 10:01 am, Jack Diederich > [For the record > ConFoo /does/ interest me, but I can't take a week and a half off to > do that plus PyCon]. CooFoo is an excellent conference. Even in the non-python tracks, there are plenty of high quality talks that would be of interest to people tracking this list. I learned quite a bit last year. Raymond -- http://mail.python.org/mailman/listinfo/python-list
Unicode Support in Ruby, Perl, Python, Emacs Lisp
here's my experiences dealing with unicode in various langs.
Unicode Support in Ruby, Perl, Python, Emacs Lisp
Xah Lee, 2010-10-07
I looked at Ruby 2 years ago. One problem i found is that it does not
support Unicode well. I just checked today, it still doesn't. Just do
a web search on blog and forums on “ruby unicode”. e.g.: Source,
Source, Source, Source.
Perl's exceedingly lousy unicode support hack is well known. In fact
it is the primary reason i “switched” to python for my scripting needs
in 2005. (See: Unicode in Perl and Python)
Python 2.x's unicode support is also not ideal. You have to declare
your source code with header like 「#-*- coding: utf-8 -*-」, and you
have to declare your string as unicode with “u”, e.g. 「u"林花謝了春紅"」. In
regex, you have to use unicode flag such as 「re.search(r'\.html
$',child,re.U)」. And when processing files, you have to read in with
「unicode(inF.read(),'utf-8')」, and printing out unicode you have to
do「outF.write(outtext.encode('utf-8'))」. If you are processing lots of
files, and if one of the file contains a bad char or doesn't use
encoding you expected, your python script chokes dead in the middle,
you don't even know which file it is or which line unless your code
print file names.
Also, if the output shell doesn't support unicode or doesn't match
with the encoding specified in your python print, you get gibberish.
It is often a headache to figure out the locale settings, what
encoding the terminal support or is configured to handle, the encoding
of your file, the which encoding the “print” is using. It gets more
complex if you are going thru a network, such as ssh. (most shells,
terminals, as of 2010-10, in practice, still have problems dealing
with unicode. (e.g. Windows Console, PuTTY. Exception being Mac's
Apple Terminal.))
Python 3 supposedly fixed the unicode problem, but i haven't used it.
Last time i looked into whether i should adopt python 3, but
apparently it isn't used much. (See: Python 3 Adoption) (and i'm quite
pissed that Python is going more and more into OOP mumbo jumbo with
lots ad hoc syntax (e.g. “views”, “iterators”, “list comprehension”.))
I'll have to say, as far as text processing goes, the most beautiful
lang with respect to unicode is emacs lisp. In elisp code (e.g.
Generate a Web Links Report with Emacs Lisp ), i don't have to declare
none of the unicode or encoding stuff. I simply write code to process
string or buffer text, without even having to know what encoding it
is. Emacs the environment takes care of all that.
It seems that javascript and PHP also support unicode well, but i
don't have extensive experience with them. I suppose that elisp, php,
javascript, all support unicode well because these langs have to deal
with unicode in practical day-to-day situations.
--
for links, see
http://xahlee.blogspot.com/2010/10/unicode-support-in-ruby-perl-python.html
Xah ∑ xahlee.org ☄
--
http://mail.python.org/mailman/listinfo/python-list
Re: frozendict (v0.1)
kj wrote: > In <[email protected]> Arnaud Delobelle writes: > > >E.g., try with {1:'a', 1j:'b'} > > I see. Thanks for this clarification. I learned a lot from it. > > I guess that frozenset must have some way of canonicalizing the > order of its elements that is dependent on their Python values but > not on their comparability. My first thought was that they are > ordered according to their hash values, but this theory doesn't > hold: > > >>> abc = ('a', 'b', 'c') > >>> sorted(map(hash, abc)) > [-468864544, -340864157, -212863774] > >>> map(hash, frozenset(abc)) > [-468864544, -212863774, -340864157] > > I.e. the ordering of the elements in the frozenset does not correspond > to the ordering of their hashes in either direction. Hmmm. > > I tried to understand this by looking at the C source but I gave > up after 10 fruitless minutes. (This has been invariably the > outcome of all my attempts at finding my way through the Python C > source.) > > I guess the take-home message is that frozenset is a more general > way to canonicalize an iterable object than sorting, even though > the reasons for this still remain a mystery to me... Then again, > just looking at the voodoo that goes into algorithms for computing > hashes fills me with despair. As much as I dislike it, sooner or > later I'll have to go on faith. Computing the hash value of a container object usually involves accumulating the hash values of its components, i.e. something like def hash(container): hashval = initial_value for x in container: hashval = f(hashval, hash(x)) return hashval Now if one chooses f such that: * f(x, y) == f(y, x) * f(x, f(y, z)) = f(f(x, y), z) (IOW, f defines a commutative and associative operation) Then it doesn't matter in what order the elements of container are enumerated, the resulting hash value will always be the same. This avoids having to find a canonical order to iterate over then elements in. -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Many newbie questions regarding python
On Thu, 7 Oct 2010 18:34:58 -0700 (PDT) alex23 wrote: > On Oct 8, 10:27 am, Steven D'Aprano cybersource.com.au> wrote: > > > v = [0 for i in range(20)] > > > > Absolutely not. Such a code snippet is very common, in fact I've > > done it myself, but it is a "hammer solution" -- to a small boy > > with a hammer, everything looks like a nail that needs hammering. > > Writing such a list comprehension is a "list comp solution". > > > > > v = [0] * 20 > > > > Yes, this is the solution. > > But the list comp version will work as expected for mutable types, > whereas the 'solution' only works for immutable types. > > If anything, I feel like the list comp version is the correct solution > because of its reliability, whereas the multiplication form feels like > either a lucky naive approach or relies on the reader to know the type > of the initialising value and its mutability. The "correct" solution is the one that works the way you want it to work (that's my definition, anyway). There is nothing "lucky" about building a list via [value]*count. It repeats (but not so much duplicates!) "value" "count" times. It is well defined (and, I think, justified) behavior. It ceases to be as useful when mutable types are involved, but so what? Use something else, then. And I think it is not too much to ask of a reader of Python to know that integers are immutable. There are enough pitfalls that make this knowledge rather important to have. (I'm actually not convinced that this works as an argument, but there you go.) TL;DR: Don't say "correct", say "appropriate". /W -- To reach me via email, replace INVALID with the country code of my home country. But if you spam me, I'll be one sour Kraut. -- http://mail.python.org/mailman/listinfo/python-list
how to handle network failures
hi I am trying to write a DataGrabber which reads some data from given url..I made DataGrabber as a Thread and want to wait for some interval of time in case there is a network failure that prevents read(). I am not very sure how to implement this class DataGrabber(threading.Thread): def __init__(self,url): threading.Thread.__init__(self) self.url=url def run(self): data=self.get_page_data() process_data(data) def get_page_data(): try: f=urllib.urlopen(self.url) data=f.read(1024) except IOError: #wait for some time and try again time.sleep(120) data=self.get_page_data() return data Is this the way to implement the part where the thread waits and reads the data again? Will this handle network failures?Can somebody please help? thanks harry -- http://mail.python.org/mailman/listinfo/python-list
Re: Ordering tests in a testsuite
But sometimes you just wanna do it the way you wanna do it. If you name your tests like 'test_01_yadda' and test_02_whatever', then they will be run in the order you want, as given by the numbers. -- http://mail.python.org/mailman/listinfo/python-list
Re: open file on mac
On Fri, 8 Oct 2010 07:16:13 -0700 (PDT) tinauser
wrote:
> on mac I get an error if i do not give the full path of initfile.py
> (commented out in the code above);
> on windows i did not have this problem.
> Am I missing anything?
open("initfile.py") opens initfile.py in the current working directory
(if you don't do anything funny, that's location where the interpreter
is started up in). I assume that you somehow start your interpreter
somewhere different on your Mac.
But that's just a guess. I don't know enough about Macs and your
environment(s) to say for sure.
/W
--
To reach me via email, replace INVALID with the country code of my home
country. But if you spam me, I'll be one sour Kraut.
--
http://mail.python.org/mailman/listinfo/python-list
Re: open file on mac
On 10/8/2010 7:16 AM tinauser said...
hi, sorry if it is a stupid qustio,but i cannot figure out where's the
problem.
i've a simpleModule:
class Starter:
def init(self,num):
print "hithere!"
print "the answer is ",num
import sys,os
print "path:",sys.path
try:
#f = open("/Users/lguerrasio/myfold/initfile.py",'r')
f = open("initfile.py",'r')
f.close()
print "huurray!"
except IOError:
print "The file does not exist, exiting gracefully"
print "This line will always print"
The module is located in the same folder of initfile.py
now,from terminal
Only guessing here, but try launching python after you cd to the folder
containing initfile.py, then start python ...
I import sys and add to the path the folder /Users/
lguerrasio/myfold; the I import the module and execute
simpleModule.Starter().init(48)
on mac I get an error if i do not give the full path of initfile.py
(commented out in the code above);
on windows i did not have this problem.
Am I missing anything?
--
http://mail.python.org/mailman/listinfo/python-list
Re: harmful str(bytes)
Steven D'Aprano writes:
>On Fri, 08 Oct 2010 15:31:27 +0200, Hallvard B Furuseth wrote:
>> That's not the point - the point is that for 2.* code which _uses_ str
>> vs unicode, the equivalent 3.* code uses str vs bytes. Yet not the same
>> way - a 2.* 'str' will sometimes be 3.* bytes, sometime str. So
>> upgraded old code will have to expect both str and bytes.
>
> I'm sorry, this makes no sense to me. I've read it repeatedly, and I
> still don't understand what you're trying to say.
OK, here is a simplified example after 2to3:
try:from urlparse import urlparse, urlunparse # Python 2.6
except: from urllib.parse import urlparse, urlunparse # Python 3.2a
foo, bar = b"/foo", b"bar" # Data from network, bar normally empty
# Statement inserted for 2.3 when urlparse below said TypeError
if isinstance(foo, bytes): foo = foo.decode("ASCII")
p = list(urlparse(foo))
if bar: p[3] = bar
print(urlunparse(p))
2.6 prints "/foo;bar", 3.2a prints "/foo;b'bar'"
You have a module which receives some strings/bytes, maybe data which
originates on the net or in a database. The module _and its callers_
may date back to before the 'bytes' type, maybe before 'unicode'.
The module is supposed to work with this data and produce some 'str's
or bytes to output. _Not_ a Python representation like "b'bar'".
The module doesn't always know which input is 'bytes' and which is
'str'. Or the callers don't know what it expects, or haven't kept
track. Maybe the input originated as bytes and were converted to
str at some point, maybe not.
Look at urrlib.parse.py and its isinstance(, )
calls. urlencode() looks particularly gross, though that one has code
which could be factored out. They didn't catch everything either, I
posted this when a 2to3'ed module of mine produced URLs with "b'bar'".
In the pre-'unicode type' Python (was that early Python 2, or should
I have said Python 1?) that was a non-issue - it Just Worked, sans
possible charset issues.
In Python 2 with unicode, the module would get it right or raise an
exception. Which helps the programmer fix any charset issues.
In Python 3, the module does not raise an exception, it produces
"b'bar'" when it was supposed to produce "bar".
>> In 2.*, str<->unicode conversion failed or produced the equivalent
>> character/byte data. Yes, there could be charset problems if the
>> defaults were set up wrong, but that's a smaller problem than in 3.*. In
>> 3.*, the bytes->str conversion always _silently_ produces garbage.
>
> So you say, but I don't see it. Why is this garbage?
To the user of the module, stuff with Python syntax is garbage. It
was supposed to be text/string data.
b = b'abc\xff'
str(b)
> "b'abc\\xff'"
>
> That's what I would expect from the str() function called with a bytes
> argument. Since decoding bytes requires a codec, which you haven't given,
> it can only return a string representation of the bytes.
>
> If you want to decode bytes into a string, you need to specify a codec:
Except I didn't intend to decode anything - I just intended to output
the contents of the string - which was stored in a 'bytes' object.
But __str__ got called because a lot of code does that. It wasn't
even my code which did it.
There's often no obvious place to decide when to consider a stream of
data as raw bytes and when to consider it text, and no obvious time
to convert between bytes and str. When writing a program, one simply
has to decide. Such as network data (bytes) vs urllib URLs (str)
in my program. And the decision is different from what one would
decide for when to use str and when to use unicode in Python 2.
In this case I'll bugreport urlunparse to python.org, but there'll be
a _lot_ of such code around. And without an Exception getting raised,
it'll take time to find it. So it looks like it'll be a long time
before I dare entrust my data to Python 3, except maybe with modules
written from scratch.
--
Hallvard
--
http://mail.python.org/mailman/listinfo/python-list
Re: open file on mac
On Fri, Oct 8, 2010 at 10:16 AM, tinauser wrote:
> hi, sorry if it is a stupid qustio,but i cannot figure out where's the
> problem.
> i've a simpleModule:
> class Starter:
>def init(self,num):
>
If you want this to execute upon declaring an instance of Starter, rename
this as __init__.
>print "hithere!"
>print "the answer is ",num
>import sys,os
>print "path:",sys.path
>
>
>try:
>#f = open("/Users/lguerrasio/myfold/initfile.py",'r')
>
Try this instead: f = open(os.path.combine('/Users/lguerrasio/myfold',
'initfile.py'),'r')
f = open("initfile.py",'r')
>f.close()
>print "huurray!"
>except IOError:
>print "The file does not exist, exiting gracefully"
>print "This line will always print"
>
>
> The module is located in the same folder of initfile.py
> now,from terminal I import sys and add to the path the folder /Users/
> lguerrasio/myfold; the I import the module and execute
> simpleModule.Starter().init(48)
>
If you had renamed the function __init__ above, all you would have to do is:
instance_of_starter = Starter(48)
Which makes more sense IMO.
Good luck!
Jason
>
> on mac I get an error if i do not give the full path of initfile.py
> (commented out in the code above);
> on windows i did not have this problem.
> Am I missing anything?
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
--
http://mail.python.org/mailman/listinfo/python-list
Re: SysLogHandler message formatting
On Oct 7, 6:18 am, Vinay Sajip wrote: > Thanks for the detailed report. I tried posting a response a couple of times, > but Google appears to have swallowed it ... trying again. Sorry if it results > in > multiple responses. Hmm, I too seem to be experiencing this problem... > The SysLogHandler aims to work within RFC 5424, though that does provide for > some flexibility in message formats. The SysLogHandler sends > formatted > message, as you've observed, with the "formatted message" part encoded in > UTF-8 > with a prepended BOM if it's Unicode. I started to read RFC 5424 yesterday before posting this, but it seemed to describe a much more complex message format than SysLogHandler was producing, so I wasn't sure if that was the reference or not. I may go back and read it completely, now that I know, though. > The existing SysLogHandler code seems to work OK with syslog, syslog-ng and > rsyslog > I agree with this, so I would normally assume that Metalog is the problem and simply stop using it. Unfortunately, I have several systems that use Metalog, and I don't want to introduce any inconsistencies by having one use something else. Switching them all would also be a hassle. > - perhaps these are more forgiving than Metalog in the way they parse > messages, or perhaps it's a Metalog configuration issue. I'd try posting this > issue to the Metalog forum / mailing list to see what feedback they can give. > I will do that; I just wanted to see what the Python stance was first. I will keep you apprised of anything determined through that route. > If you do think it's a bug in SysLogHandler then please create an issue on > bugs.python.org and assign it to me, so I can take a look at it After I communicate with the Metalog community, I will definitely file an issue if necessary. I didn't want to jump the gun, though. > I think using an appropriate Formatter will ensure interoperability in any > particular scenario. I don't especially want to hard-code any format into > SysLogHandler, since a Formatter can be used to set the format flexibly. I think the only problem with doing it that way is that I wasn't initially aware that using a Formatter affected how the message is sent to Syslog, but assumed it only modified the visible portion. I will admit that, until yesterday, I knew nothing of the syslog protocol. Perhaps the best solution would be to simply document the fact that adjusting the message format can affect how the message is parsed by the syslog daemon receiving it. Thank you for your feedback. -- http://mail.python.org/mailman/listinfo/python-list
Re: open file on mac
On Fri, Oct 8, 2010 at 3:39 PM, Jason Swails wrote:
>
>
> On Fri, Oct 8, 2010 at 10:16 AM, tinauser wrote:
>
>> hi, sorry if it is a stupid qustio,but i cannot figure out where's the
>> problem.
>> i've a simpleModule:
>> class Starter:
>>def init(self,num):
>>
>
> If you want this to execute upon declaring an instance of Starter, rename
> this as __init__.
>
>
>>print "hithere!"
>>print "the answer is ",num
>>import sys,os
>>print "path:",sys.path
>>
>>
>>try:
>>#f = open("/Users/lguerrasio/myfold/initfile.py",'r')
>>
>
> Try this instead: f = open(os.path.combine('/Users/lguerrasio/myfold',
> 'initfile.py'),'r')
>
Gah, stupid. os.path.join, not os.path.combine. I'm down for the golf
thing...
>
>f = open("initfile.py",'r')
>>f.close()
>>print "huurray!"
>>except IOError:
>>print "The file does not exist, exiting gracefully"
>>print "This line will always print"
>>
>>
>> The module is located in the same folder of initfile.py
>> now,from terminal I import sys and add to the path the folder /Users/
>> lguerrasio/myfold; the I import the module and execute
>> simpleModule.Starter().init(48)
>>
>
> If you had renamed the function __init__ above, all you would have to do
> is:
>
> instance_of_starter = Starter(48)
>
> Which makes more sense IMO.
>
> Good luck!
> Jason
>
>
>>
>> on mac I get an error if i do not give the full path of initfile.py
>> (commented out in the code above);
>> on windows i did not have this problem.
>> Am I missing anything?
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>
>
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Graduate Student
> 352-392-4032
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
--
http://mail.python.org/mailman/listinfo/python-list
question about a program
question about an assignment:
>>> places("home sweet home is here",' ')
[4, 10, 15, 18]
this is my code:
def places(x, y):
return [x.index(y) for v in x if (v == y)]
so far I'm only getting
[4, 4, 4, 4]
so the first value is correct, it is just not iterating on to the next
three items it needs to
--
http://mail.python.org/mailman/listinfo/python-list
Re: Many newbie questions regarding python
On Oct 7, 4:10 pm, Rogério Brito wrote:
[snip]
>
> v = [0 for i in range(20)]
>
> v = [0] * 20
>
> v = []
> for i in range(20): v.append(0)
>
> What should I prefer? Any other alternative?
The Pythonic way is to not to preinitialize the list at all. Don't
put anything in the list until you have the data you need.
> If possible, I would like to simply declare the list and fill it latter in my
> program, as lazily as possible (this happens notoriously when one is using a
> technique of programming called dynamic programming where initializing all
> positions of a table may take too much time in comparison to the filling of
> the
> array).
So, if I understand you, you are thinking of your list as a table with
dynamically calculated entries, and want to calculate the entries upon
request.
Three possibilities:
1. Initialize the list using v = [None]*n (I recomment using None
instead of 0 for this, in most cases)
2. Use a dict instead. Dict items pop into existence if you assign
with a key that doesn't exist.
v = {}
Then you can do
v[1] = a
v[10] = n
v[999] = c
3. Consider numpy, which allows preallocation of lists:
v = np.zeros(100)
[snip]
> For instance, if I
> define:
>
> class C:
> f = 1
> def g(self):
> return f
>
> I get an annoying message when I try to call the g method in an object of type
> C, telling me that there's no global symbol called f. If I make g return
> self.f
> instead, things work as expected, but the code loses some readability.
>
> Is there any way around this or is that simply "a matter of life"?
Matter of life. It's that way by design.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Re: question about a program
On Thu, 7 Oct 2010 17:39:51 -0700 (PDT) Logan Butler
wrote:
> question about an assignment:
>
> >>> places("home sweet home is here",' ')
> [4, 10, 15, 18]
>
> this is my code:
>
> def places(x, y):
> return [x.index(y) for v in x if (v == y)]
>
> so far I'm only getting
> [4, 4, 4, 4]
>
> so the first value is correct, it is just not iterating on to the next
> three items it needs to
list.index(x)
Return the index in the list of the first item whose value is x. It
is an error if there is no such item.
/W
--
To reach me via email, replace INVALID with the country code of my home
country. But if you spam me, I'll be one sour Kraut.
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Fri, Oct 8, 2010 at 1:26 PM, Steven D'Aprano wrote: > On Fri, 08 Oct 2010 10:21:16 +0200, Antoon Pardon wrote: > >> Personnaly I find it horrible >> that in the following expression: L[a:b:-1], it is impossible to give a >> numeric value to b, that will include L[0] into the reversed slice. > > > L = [1, 2, 3, 4, 5] L[5:-6:-1] > [5, 4, 3, 2, 1] >>> a = [1, 2, 3, 4, 5, 6] >>> a[::-1] [6, 5, 4, 3, 2, 1] -- Jed Smith [email protected] -- http://mail.python.org/mailman/listinfo/python-list
Re: question about a program
On Oct 8, 1:39 am, Logan Butler wrote:
> question about an assignment:
>
> >>> places("home sweet home is here",' ')
>
> [4, 10, 15, 18]
>
> this is my code:
>
> def places(x, y):
> return [x.index(y) for v in x if (v == y)]
>
> so far I'm only getting
> [4, 4, 4, 4]
>
> so the first value is correct, it is just not iterating on to the next
> three items it needs to
Try this instead:
def places(x, y):
return [i for i, v in enumerate(x) if v == y]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Opening a webpage in the background via webbrowser.open()
2010/10/7 : > Python 2.7 (32-bit/Windows): Is there a way to use webbrowser.open() to open > a web page in the default browser, but in the background, so that the > application making the webbrowser.open() call remains the active > application? > > Thank you, > Malcolm > -- > http://mail.python.org/mailman/listinfo/python-list > > It seems, there might not be a straightforward way for doing this. As you probably found out, webbrowser.open has a parameter "autoraise" just for specifying this behaviour: webbrowser.open(url[, new=0[, autoraise=True]]) however, the sidenote in the docs also seems to apply: "If autoraise is True, the window is raised if possible (note that under many window managers this will occur regardless of the setting of this variable)." http://docs.python.org/library/webbrowser.html#webbrowser.open For me (win XP, python 2.5.4) the browser window is always raised after this call, regardless the autoraise option. Possibly, if you are using a gui app, the focus can be maintained form there, in order to avoid activating the browser, otherwise it might be more complicated. (maybe the pywin package might have some means for achieving this?) vbr -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
Jed Smith writes: a = [1, 2, 3, 4, 5, 6] a[::-1] > [6, 5, 4, 3, 2, 1] Nice. Is there a trick to get a "-0" index too? Other than doing 'i or len(L)' instead of 'i', that is. >>> L = [1,2,3,4,5] >>> L[2:-2], L[2:-1], L[2:-0] # not quite right:-) ([3], [3, 4], []) -- Hallvard -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
Jed Smith writes: > On Fri, Oct 8, 2010 at 1:26 PM, Steven D'Aprano > wrote: >> On Fri, 08 Oct 2010 10:21:16 +0200, Antoon Pardon wrote: >> >>> Personnaly I find it horrible >>> that in the following expression: L[a:b:-1], it is impossible to give a >>> numeric value to b, that will include L[0] into the reversed slice. ^^ >> >> >> > L = [1, 2, 3, 4, 5] > L[5:-6:-1] >> [5, 4, 3, 2, 1] > a = [1, 2, 3, 4, 5, 6] a[::-1] > [6, 5, 4, 3, 2, 1] b doesn't have a numeric value though. -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
Hallvard B Furuseth writes: > Jed Smith writes: > a = [1, 2, 3, 4, 5, 6] > a[::-1] >> [6, 5, 4, 3, 2, 1] > > Nice. Is there a trick to get a "-0" index too? > Other than doing 'i or len(L)' instead of 'i', that is. > L = [1,2,3,4,5] L[2:-2], L[2:-1], L[2:-0] # not quite right:-) > ([3], [3, 4], []) 'i or None' -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: open file on mac
On Fri, Oct 8, 2010 at 10:41 AM, tinauser wrote:
> hallo, i'm sorry if the question is very stupid, but i cannot
> understand what i'm doing wrong here.
>
> i have this myModule.py
>
> class Starter:
>def init(self,num):
>print "hithere!"
>print "the answer is ",num
>import sys,os
>print "path:",sys.path
> print "bye"
>
>try:
> ##f = open("/Users/lguerrasio/_myfold/initfile.py",'r')
>f = open("initfile.py",'r')
>f.close()
>print "huurray!"
>except IOError:
>print "The file does not exist, exiting gracefully"
>print "This line will always print"
>
>
> the module is in the same folder of initfile
> from terminal, i import sys and add to the path /Users/lguerrasio/
> _myfold/;
> then i import the module and call
> myModule.Starter().init(9)
>
> now,the file will be opened only if i give the full path, not if i
> give only the name of the file, although the folder is in the path.
> what am I missing?
>
sys.path, unless I've missed something, has nothing to do with *opening* a
file. It has to do with importing a python module, so it should have no
affect on your ability to simply open a file.
On my mac, in the interpreter, running open() on a file in the same
directory reported by os.path.abspath(os.path.curdir) succeeds without
issue.
What you might consider is doing something like
open(os.path.join(os.path.dirname(__file__), 'initfile.py')
That will insure that it always tries to open the file that's in the same
directory as the module trying to open it, assuming that's what you want.
If what you want is an import and not an open(), well... let us know :)
brian
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
Brian K. Jones
My Blog http://www.protocolostomy.com
Follow me http://twitter.com/bkjones
--
http://mail.python.org/mailman/listinfo/python-list
Re: harmful str(bytes)
On Fri, 08 Oct 2010 15:45:58 +0200
Hallvard B Furuseth wrote:
> Antoine Pitrou writes:
> >Hallvard B Furuseth wrote:
> >> The offender is bytes.__str__: str(b'foo') == "b'foo'".
> >> It's often not clear from looking at a piece of code whether
> >> some data is treated as strings or bytes, particularly when
> >> translating from old code. Which means one cannot see from
> >> context if str(s) or "%s" % s will produce garbage.
> >
> > This probably comes from overuse of str(s) and "%s". They can be useful
> > to produce human-readable messages, but you shouldn't have to use them
> > very often.
>
> Maybe Python 3 has something better, but they could be hard to avoid in
> Python 2. And certainly our site has plenty of code using them, whether
> we should have avoided them or not.
It's difficult to answer more precisely without knowing what you're
doing precisely. But if you already have str objects, you don't have to
call str() or format them using "%s", so implicit __str__ calls are
avoided.
> > Actually, the implicit contract of __str__ is that it never fails, so
> > that everything can be printed out (for debugging purposes, etc.).
>
> Nope:
>
> $ python2 -c 'str(u"\u1000")'
> Traceback (most recent call last):
[...]
> $ python2 -c 'unicode("\xA0")'
> Traceback (most recent call last):
Sure, but so what? This mainly shows that unicode support was broken in
Python 2, because:
1) it tried to do implicit bytes<->unicode coercion by using some
process-wide default encoding
2) some unicode objects didn't have a succesful str()
Python 3 fixes both these issues. Fixing 1) means there's no automatic
coercion when trying to mix bytes and unicode. Try for example:
[Python 2] >>> u"a" + "b"
u'ab'
[Python 3] >>> "a" + b"b"
Traceback (most recent call last):
File "", line 1, in
TypeError: Can't convert 'bytes' object to str implicitly
And fixing 2) means bytes object get a meaningful str() in all
circumstances, which is much better for debug output.
If you don't think that 2) is important, then perhaps you don't deal
with non-ASCII data a lot. Failure to print out exception messages (or
log entries, etc.) containing non-ASCII characters is a big annoyance
with Python 2 for many people (including me).
> In Python 2, these two UnicodeEncodeErrors made our data safe from code
> which used str and unicode objects without checking too carefully which
> was which.
That's false, since implicit coercion can actually happen everywhere.
And it only fails when there's non-ASCII data involved, meaning the
unsuspecting Anglo-saxon developer doesn't understand why his/her users
complain.
Regards
Antoine.
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On 10/8/2010 4:21 AM, Antoon Pardon wrote:
On Wed, Oct 06, 2010 at 05:28:13PM -0400, Terry Reedy wrote:
Strings and tuples are not natural numbers, but do have least
members ('' and ()), so the bottom end had better be closed.
Why?
Because otherwise one can never include the least member in a slice.
> The fact that we have a bottom element in the item space,
doesn't imply that the sequence I need is easiest defined by
using an inclusive lower limit. What if I wanted all none-empty
strings/tuples keys in the tree?
Use 'a' as the lower bound, it being the string that follows ''.
But you really seem to be saying is "What if I sometimes want the end
points included and sometimes do not?" Slice syntax by itself cannot
handle all four cases, only one, one was chosen and that was closed-open.
If you want flexibility, consider the following:
class my_list(list):
def __getitem__(self, key, include_start=True, include_stop=False):
if (isinstance(key,tuple) and len(key)==2 and
isinstance(key[0], slice)
and isinstance(key[1],tuple) and len(key[1])==2):
key, (include_start, include_stop) = key
start,stop,stride = key.indices(len(self))
if include_start == False:
start += 1
if include_stop == True:
stop += 1
key = slice(start,stop,stride)
print(key)
return list.__getitem__(self, key)
ll = my_list(range(10))
print('standard:', ll[2], ll[1:3], ll[1:3,(True,False)])
print('delete start:', ll[1:3,(False,False)])
print('shift:', ll[1:3,(False,True)])
print('extend stop:', ll[1:3,(True,True)])
>>>
slice(1, 3, 1)
standard: 2 [1, 2] [1, 2]
slice(2, 3, 1)
delete start: [2]
slice(2, 4, 1)
shift: [2, 3]
slice(1, 4, 1)
extend stop: [1, 2, 3]
>>>
Modify to taste ;-)
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Sys.exit in secondary threads
In article , Pakal wrote: > I've noticed that there is nothing in python's documentation regarding > the use of sys.exit(code) in a non-main thread. > > As far as I've seen, the behaviour in this case is to simply exit the > thread, without caring about the return code. in the main thread > however, the return code becomes the official return code of the whole > process. > > Is that all we have to say about sys.exit() in a multithreaded > program ? Or are there corner cases I've missed ? We'd better document > this anyway. There is this item among the Caveats for the _thread module in Py3 (thread in Py2): "Calling sys.exit() or raising the SystemExit exception is equivalent to calling _thread.exit()." http://docs.python.org/py3k/library/_thread.html http://docs.python.org/library/thread.html It seems like it should be mentioned elsewhere, too, like in sys.exit() itself. Doc patches would be welcomed, I'm sure. -- Ned Deily, [email protected] -- http://mail.python.org/mailman/listinfo/python-list
Re: if the else short form
"NevilleDNZ" wrote in message news:[email protected]... On Oct 7, 9:23 am, Lawrence D'Oliveiro wrote: x = {1 : "One", 2 : "Two", 3 : "Three"}.get(i, "None Of The Above") More like: x = {1:lambda:"One", 2:lambda:"Two", 3:lambda:"Three"}.get(i, lambda:"None Of The Above")() i.e. deferred evaluation of selected case. In Algol68 this would be: x:=(i|"One","Two","Three"|"None Of The Above") The point is, the construction works well when the syntax fully supports it. When it needs the extra clutter that Python demands, it might not be so worthwhile. Especially as it's not clear whether, even with lambdas, an entire dictionary needs to be constructed before a selection can be made. In fact a brief test showed an list+if (or is it tuple? I can never remember) construction was much faster and much cleaner: x = ("One","Two","Three")[i-1] if 1<=i<=3 else "Other" "NevilleDNZ" wrote: "BartC" wrote: Probably there are workarounds here too, but I suspect the syntax won't be quite as pert as the Algol68-style example: x = (i | "Zero", "One", "Two" | "None of the above") # 0-based /* ¢ Algol68 case clause is 1-based. ¢ */ Yes, but my example was in Algol68-*style*: 0-based pseudo-syntax just in case the Pythonians here couldn't get their heads around 1-based indexing.. (I've borrowed a lot from Algol68 when I've needed to design language syntax (naturally, just the best bits), and I do normally use 1-based.) -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: question about a program
On Thu, Oct 7, 2010 at 5:39 PM, Logan Butler wrote:
> question about an assignment:
>
places("home sweet home is here",' ')
> [4, 10, 15, 18]
>
> this is my code:
>
> def places(x, y):
> return [x.index(y) for v in x if (v == y)]
>
> so far I'm only getting
> [4, 4, 4, 4]
>
> so the first value is correct, it is just not iterating on to the next
> three items it needs to
Your loop variable is v, but your expression `x.index(y)` does not use
v at all, and hence its value is invariant over the course of the
loop.
Cheers,
Chris
--
http://blog.rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list
Unicode Decode Error
UnicodeDecodeError: 'ascii' codec can't decode byte 0x92 in position 152: ordinal not in range(128). Can someone please help me with this error The error occurs in line wbk.save(p4_merge.xls). I have used import xlwt..Can someone just tell what do I need to do to get rid of this error. I read other forums which explain the error but do not solve it. Thanks in advance.. -- http://mail.python.org/mailman/listinfo/python-list
Re: harmful str(bytes)
On 10/8/2010 9:45 AM, Hallvard B Furuseth wrote:
Actually, the implicit contract of __str__ is that it never fails, so
that everything can be printed out (for debugging purposes, etc.).
Nope:
$ python2 -c 'str(u"\u1000")'
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\u1000' in position
0: ordinal not in range(128)
This could be considered a design bug due to 'str' being used both to
produce readable string representations of objects (perhaps one that
could be eval'ed) and to convert unicode objects to equivalent string
objects. which is not the same operation!
The above really should have produced '\u1000'! (the equivavlent of what
str(bytes) does today). The 'conversion to equivalent str object' option
should have required an explicit encoding arg rather than defaulting to
the ascii codec. This mistake has been corrected in 3.x, so Yep.
And the equivalent:
$ python2 -c 'unicode("\xA0")'
Traceback (most recent call last):
File "", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa0 in position 0: ordinal
not in range(128)
This is an application bug: either bad string or missing decoding arg.
In Python 2, these two UnicodeEncodeErrors made our data safe from code
which used str and unicode objects without checking too carefully which
was which. Code which sort the types out carefully enough would fail.
In Python 3, that safety only exists for bytes(str), not str(bytes).
If you prefer the buggy 2.x design (and there are *many* tracker bug
reports that were fixed by the 3.x change), stick with it.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: harmful str(bytes)
On 10/8/2010 9:31 AM, Hallvard B Furuseth wrote: That's not the point - the point is that for 2.* code which _uses_ str vs unicode, the equivalent 3.* code uses str vs bytes. Yet not the same way - a 2.* 'str' will sometimes be 3.* bytes, sometime str. So upgraded old code will have to expect both str and bytes. If you want to interconvert code between 2.6/7 and 3.x, use unicode and bytes in the 2.x code. Bytes was added to 2.6/7 as a synonym for str explicitly and only for conversion purposes. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
script in Linux vs Windows
Hi all,
Unsure how to deal with what appears to be \n vs \r issues.
The following code works in Linux;
o = open("axenfs.reg")
n = open("axenfs2.reg", "a")
while 1:
line = o.readline()
if not line: break
line = line.replace("dword:0","dword:044e")
n.write(line)
n.close()
But in Windows, its one continues line with a bunch of squares in it.
So I add + '\r\n' to my second to last line so it looks like;
n.write(line + '\r\n')
But I still get one continuous line with squares in it.
Any ideas? I've been googing all day to no avail.
Desperately seeking advice.
- aurf
--
http://mail.python.org/mailman/listinfo/python-list
Re: Simple database explorer
On Fri, 08 Oct 2010 02:04:39 -0700, dusans wrote: > On Oct 7, 7:49 am, Lawrence D'Oliveiro central.gen.new_zealand> wrote: >> In message >> <21c99273-ed58-4f93-b98a-d9292de5d...@k10g2000yqa.googlegroups.com>, >> dusans wrote: >> >> > - all the others having ODBC drivers... >> >> ODBC seems to be something you use when you can’t use a proper database >> driver. > Its the right answer for a program that needs to be used with many different RDBMSes, especially if you use its metadata access procedures. > yes. first i have been mixing native and odbc drivers. Now i only use > odbc. Odbc is not the best but its good enought for a sql explorer. Dont > know how its on unix thou > Use unixODBC. Its a wrapper that lets Windows ODBC drivers be run on UNIX/ Linux and there's a Python module that provides an interface to unixODBC and a Data Manager utility that configures ODBC data sources. The documentation for the module is poor but the module and utility both work well once you've figured out how to use them. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] Inclusive Range
On Oct 8, 3:05 pm, Terry Reedy wrote: > > doesn't imply that the sequence I need is easiest defined by > > using aninclusivelower limit. What if I wanted all none-empty > > strings/tuples keys in the tree? > > Use 'a' as the lower bound, it being the string that follows ''. No, that would be '\0'. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode Decode Error
On Fri, Oct 8, 2010 at 2:31 PM, Pratik Khemka wrote: > UnicodeDecodeError: 'ascii' codec can't decode byte 0x92 in position 152: > ordinal not in range(128). Can someone please help me with this error > The error occurs in line wbk.save(p4_merge.xls). I have used > import xlwt..Can someone just tell what do I need to do to get rid of this > error. I read other forums which explain the error but do not solve it. (1) Always include the *full* exception Traceback. (2) Check whether your version of xlwt is up-to-date. (3) You might have more luck asking on xlwt's newsgroup: http://groups.google.com/group/python-excel Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode Decode Error
On Fri, Oct 8, 2010 at 3:31 PM, Pratik Khemka wrote:
> *UnicodeDecodeError: 'ascii' codec can't decode byte 0x92 in position
> 152: ordinal not in range(128)*. Can someone please help me with this
> error
> The error occurs in line *wbk.save(p4_merge.xls)*. I have used *
> import xlwt*..Can someone just tell what do I need to do to get rid of
> this error. I read other forums which explain the error but do not solve it.
> Thanks in advance..
>
>
You're writing non-ascii data to the workbook, which is then trying to
decode it using the default ascii encoding, which will fail. When you
create the workbook, you need to specify the correct encoding, e.g.:
wbk = xlwt.Workbook('utf-8')
or whatever encoding you're actually using.
Cheers,
Ian
--
http://mail.python.org/mailman/listinfo/python-list
script in Linux vs Windows
Hi all,
Unsure how to deal with what appears to be \n vs \r issues.
The following code works in Linux;
o = open("axenfs.reg")
n = open("axenfs2.reg", "a")
while 1:
line = o.readline()
if not line: break
line = line.replace("dword:0","dword:044e")
n.write(line)
n.close()
But in Windows, its one continues line with a bunch of squares in it.
So I add + '\r\n' to my second to last line so it looks like;
n.write(line + '\r\n')
But I still get one continuous line with squares in it.
Any ideas? I've been googing all day to no avail.
Desperately seeking advice.
- aurf
--
http://mail.python.org/mailman/listinfo/python-list
Re: question about a program
On Fri, 8 Oct 2010 14:34:21 -0700 Chris Rebert
wrote:
> On Thu, Oct 7, 2010 at 5:39 PM, Logan Butler
> wrote:
> > question about an assignment:
> >
> places("home sweet home is here",' ')
> > [4, 10, 15, 18]
> >
> > this is my code:
> >
> > def places(x, y):
> > return [x.index(y) for v in x if (v == y)]
> >
> > so far I'm only getting
> > [4, 4, 4, 4]
> >
> > so the first value is correct, it is just not iterating on to the
> > next three items it needs to
>
> Your loop variable is v, but your expression `x.index(y)` does not use
> v at all, and hence its value is invariant over the course of the
> loop.
>
Nice catch, but the "if (v==y)" clause nullifies that in any case.
The real reason is that list.index(x) returns the index of the *first*
occurrence of x, so its invariant by default.
/W
--
To reach me via email, replace INVALID with the country code of my home
country. But if you spam me, I'll be one sour Kraut.
--
http://mail.python.org/mailman/listinfo/python-list
Re: script in Linux vs Windows
On Fri, Oct 8, 2010 at 3:52 PM, wrote:
> Hi all,
>
> Unsure how to deal with what appears to be \n vs \r issues.
>
> The following code works in Linux;
>
> o = open("axenfs.reg")
> n = open("axenfs2.reg", "a")
> while 1:
> line = o.readline()
> if not line: break
> line = line.replace("dword:0","dword:044e")
> n.write(line)
> n.close()
>
> But in Windows, its one continues line with a bunch of squares in it.
>
> So I add + '\r\n' to my second to last line so it looks like;
>
> n.write(line + '\r\n')
>
> But I still get one continuous line with squares in it.
>
> Any ideas? I've been googing all day to no avail.
>
Is the input file formatted the same way? I would guess that the readline
call is reading the input file as one continuous line, so that the loop body
only runs once, and the '\r\n' only gets added to the very end of the file.
The simplest way to deal with this type of issue is to convert the file line
endings as needed using dos2unix and unix2dos.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Opening a webpage in the background via webbrowser.open()
On 10/08/10 15:11, Vlastimil Brom wrote: webbrowser.open(url[, new=0[, autoraise=True]]) however, the sidenote in the docs also seems to apply: "If autoraise is True, the window is raised if possible (note that under many window managers this will occur regardless of the setting of this variable)." http://docs.python.org/library/webbrowser.html#webbrowser.open For me (win XP, python 2.5.4) the browser window is always raised after this call, regardless the autoraise option. And with my configuration (Linux, fluxbox) of the browser full-screen on one virtual desktop and usually working in other desktops, this almost *never* happens to me, regardless of the auto-raise option :) -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Help with sets
Lawrence D'Oliveiro wrote: Did you know that applying the “set” or “frozenset” functions to a dict return a set of its keys? Seems a bit dodgy, somehow. That's just a consequence of the fact that dicts produce their keys when iterated over, and the set constructor iterates over whatever you give it. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: script in Linux vs Windows
On 08/10/2010 22:52, [email protected] wrote: Hi all, Unsure how to deal with what appears to be \n vs \r issues. The following code works in Linux; o = open("axenfs.reg") n = open("axenfs2.reg", "a") while 1: line = o.readline() if not line: break line = line.replace("dword:0","dword:044e") n.write(line) n.close() But in Windows, its one continues line with a bunch of squares in it. So I add + '\r\n' to my second to last line so it looks like; n.write(line + '\r\n') But I still get one continuous line with squares in it. Any ideas? I've been googing all day to no avail. Desperately seeking advice. Open the input file in binary mode and print out the repr for a few lines to see what the file encoding and line ending actually is. That always helps me. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: script in Linux vs Windows
On Oct 8, 2010, at 4:27 PM, Ian Kelly wrote:
On Fri, Oct 8, 2010 at 3:52 PM, wrote:
Hi all,
Unsure how to deal with what appears to be \n vs \r issues.
The following code works in Linux;
o = open("axenfs.reg")
n = open("axenfs2.reg", "a")
while 1:
line = o.readline()
if not line: break
line = line.replace("dword:0","dword:044e")
n.write(line)
n.close()
But in Windows, its one continues line with a bunch of squares in it.
So I add + '\r\n' to my second to last line so it looks like;
n.write(line + '\r\n')
But I still get one continuous line with squares in it.
Any ideas? I've been googing all day to no avail.
Is the input file formatted the same way? I would guess that the
readline call is reading the input file as one continuous line, so
that the loop body only runs once, and the '\r\n' only gets added to
the very end of the file.
Hi Ian,
Thanks very much for the reply.
It took a very long time to get my approval mail for this list, so in
the interum, I fix it this way (in the event other noobs have issues
like myself).
First, I replaced "a" with "ab" as Winblows treats text files diff
then Unix.
Second, I used variables instead of actual text so "dword:0" is
really a var named oldhexuid. And "dword:044e" is really a new
var called newhexuid.
What I am really doing here is using NFS in 64 bit Windows XP via
AxeNFS client which also works in Windows 7.
If you are asking why as Windows 7 does have NFS, it does not map UIDs
like Windows XP 32 + SFU can do. So basically I load an LDAP plugin
for Windows called pGina which is an LDAP client for Windows.
Then during login, I NFS mount, scan a Linux passwd file on that NFS
mount for the matching UID of the logged in Windows user and mod the
reg so that the windows user UID matches the Linux UID.
This way when they mod a file/ folder on the NFS mount, its got
proper UID/GID values system wide.
Its really too bad the Windows 7 doesn't support NFS map files in
terms of matching users with UID/GID.
And I didn't want to use Samba as I like my OpenLDAP servers clean and
tidy.
Since the reg value is in hex, I had to convert the decimal value
derived from the passwd file to hex via a sysinternals program called
hex2dec. Its this value that I use to mod the reg for AxeNFS.
This was a royal PITA but my constraints were clear and no flexible.
Hope this helps others.
- aurf
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Fri, 08 Oct 2010 15:53:17 -0400, Jed Smith wrote: > On Fri, Oct 8, 2010 at 1:26 PM, Steven D'Aprano > wrote: >> On Fri, 08 Oct 2010 10:21:16 +0200, Antoon Pardon wrote: >> >>> Personnaly I find it horrible >>> that in the following expression: L[a:b:-1], it is impossible to give >>> a numeric value to b, that will include L[0] into the reversed slice. >> >> >> > L = [1, 2, 3, 4, 5] > L[5:-6:-1] >> [5, 4, 3, 2, 1] > a = [1, 2, 3, 4, 5, 6] a[::-1] > [6, 5, 4, 3, 2, 1] Well of course that works, that is the standard Python idiom for reversing a sequence. But the point was that Antoon claimed that there is no numeric value for the end position that will include L[0] in the reversed slice. My example shows that this is not correct. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] [Python-Dev] Inclusive Range
On Fri, 08 Oct 2010 22:10:35 +0200, Hallvard B Furuseth wrote:
> Jed Smith writes:
> a = [1, 2, 3, 4, 5, 6]
> a[::-1]
>> [6, 5, 4, 3, 2, 1]
>
> Nice. Is there a trick to get a "-0" index too? Other than doing 'i or
> len(L)' instead of 'i', that is.
What exactly are you expecting? I don't understand why you think that
L[-0] and L[0] would be different, when -0 == 0. I'm also unsure why you
think that there's anything more ("too") to get -- the example shown
reverses the entire list.
Perhaps if you show what result you are expecting, we can show what slice
to give to get it.
L = [1,2,3,4,5]
L[2:-2], L[2:-1], L[2:-0] # not quite right:-)
> ([3], [3, 4], [])
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: question about a program
On Thu, 07 Oct 2010 17:39:51 -0700, Logan Butler wrote:
> question about an assignment:
>
places("home sweet home is here",' ')
> [4, 10, 15, 18]
>
> this is my code:
>
> def places(x, y):
> return [x.index(y) for v in x if (v == y)]
>
> so far I'm only getting
> [4, 4, 4, 4]
>
> so the first value is correct, it is just not iterating on to the next
> three items it needs to
Not every tool is a hammer, not every list builder needs to be a list
comp, and not every function needs to be a one-liner. The simplest way to
deal with this is to do an explicit loop.
Also, your names "x" and "y" are misleading. It is conventional to expect
x and y to be numeric values, so it is best to pick more descriptive
names.
def places(s, sub):
"""Return indexes into string s where non-overlapping copies
of substring sub is found, or [-1] if not found at all.
"""
n = len(sub)
start = 0
indexes = []
try:
while True:
i = s.index(sub, start)
indexes.append(i)
start = i + n
except ValueError:
if not indexes: indexes = [-1]
return indexes
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Many newbie questions regarding python
On Thu, 07 Oct 2010 18:34:58 -0700, alex23 wrote: > On Oct 8, 10:27 am, Steven D'Aprano cybersource.com.au> wrote: >> > v = [0 for i in range(20)] >> >> Absolutely not. Such a code snippet is very common, in fact I've done >> it myself, but it is a "hammer solution" -- to a small boy with a >> hammer, everything looks like a nail that needs hammering. Writing such >> a list comprehension is a "list comp solution". >> >> > v = [0] * 20 >> >> Yes, this is the solution. > > But the list comp version will work as expected for mutable types, > whereas the 'solution' only works for immutable types. Yes, that is a good point. Repeating the same mutable object may give surprising results. > If anything, I feel like the list comp version is the correct solution > because of its reliability, whereas the multiplication form feels like > either a lucky naive approach or relies on the reader to know the type > of the initialising value and its mutability. And how often do you have an list that you are creating where you don't know what items you have to initialise the list with? There are three common use-cases for the idiom the OP was describing: initialising a list with zeroes (or sometimes some other numeric value), initialising it with None, or creating a list-of-lists (or more rarely, a list-of-dicts). The first one is *far* more common than the next two. You are right to point out that the third case is a Python gotcha: [[]]*n doesn't behave as expected by the naive or inexperienced Python programmer. I should have mentioned it, and pointed out that in that case you do want a list comp [[] for i in range(n)]. But that doesn't mean that the list comp is the general purpose solution. Consider the obvious use of the idiom: def func(arg, count): # Initialise the list. L = [arg for i in range(count)] # Do something with it. process(L, some_function) def process(L, f): # Do something with each element. for item in enumerate(L): f(item) Looks good, right? But it isn't, because it will suffer the exact same surprising behaviour if f modifies the items in place. Using a list comp doesn't save you if you don't know what the object is. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
