twitter: comp.lang.python - 25 new messages in 11 topics

comp.lang.python
http://groups.google.com/group/comp.lang.python?hl=en

comp.lang.python@googlegroups.com

Today's topics:

==============================================================================
TOPIC: Queue peek?
http://groups.google.com/group/comp.lang.python/t/ba3cb62c81d4cb7a?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 5:00 pm
From: MRAB

John Krukoff wrote:
> On Tue, 2010-03-02 at 22:54 +0100, mk wrote:
> <snip>
>> No need to use synchro primitives like locks?
>>
>> I know that it may work, but that strikes me as somehow wrong... I'm
>> used to using things like Lock().acquire() and Lock().release() when
>> accessing shared data structures, whatever they are.
> <snip>
>
> This is one of those places where the GIL is a good thing, and makes
> your life simpler. You could consider it that the interpreter does the
> locking for you for such primitive operations, if you like.

I suppose it depends on the complexity of the data structure. A dict's
methods are threadsafe, for example, but if you have a data structure
where access leads to multiple method calls then collectively they need
a lock.

== 2 of 2 ==
Date: Tues, Mar 2 2010 10:14 pm
From: Gregory Ewing

MRAB wrote:

> I suppose it depends on the complexity of the data structure. A dict's
> methods are threadsafe, for example, but if you have a data structure
> where access leads to multiple method calls then collectively they need
> a lock.

It also depends on the nature of the objects being used
as dict keys. Dict operations invoke the hashing and
comparison methods of the keys, which in general can
execute arbitrary Python code.

If the keys are elementary built-in types such as
strings or ints, then dict operations will *probably*
be atomic. But I think I'd use a lock anyway, to be
on the safe side.

--
Greg

==============================================================================
TOPIC: Multiprocessing problem
http://groups.google.com/group/comp.lang.python/t/3909e9c08cc8efe1?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 5:07 pm
From: Matt Chaput

> If the main process doesn't get the results from the queue until the
> worker processes terminate, and the worker processes don't terminate
> until they've put their results in the queue, and the pipe consequently
> fills up, then deadlock can result.

The queue never fills up... on platforms with qsize() I can see this. I
remove items from the results queue as I add to the job queue, and if I
add timeouts everywhere the workers never raise Empty and the supervisor
never raises Full. They just deadlock.

I've rewritten the code so the worker threads don't push information
back while they run, they just write to a temporary file which the
supervisor can read, which avoids the issue. But if anyone can tell me
what I was doing wrong for future reference, I'd greatly appreciate it.

Thanks,

Matt

==============================================================================
TOPIC: Multiprocessing.Pipe is not concurrently bi-directional (design flaw?)
http://groups.google.com/group/comp.lang.python/t/fabd29d620a303b8?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Mar 2 2010 5:45 pm
From: Metalone

I wanted to use Multiprocessing.Pipe and Multiprocessing.Process to
peform Actor style communication.
However, I just can't get what I need done, and I think it is due to
inherit problems with the design of Pipe.

If I have a process like this
def process1(conn):
while True:
msg = conn.recv()
if msg == 'go':
res = go() # this is a long running function
conn.send(res) # send result back to caller
elif msg == 'stop':
stop() # this is intended to stop the go() function, for
example using deciding to abort operation.

In this code the 'stop' message cannot be received, because the code
is in the long running go() function.
So lets change it.

def process1(conn):
while True:
msg = conn.recv()
if msg == 'go':
t = threading.Thread(target=go, args=(conn,))
t.start()
elif msg == 'stop':
stop() # this is intended to stop the go() function.

Now the thread-1 is waiting on the blocking recv().
If the go() function completes on thread-2, it wants to send its
result via the connection object, but it can't because
the connection is in use.

Trying to work around this gets complicated.
For example, using a second process and a second connection object to
read the 'stop' message, and then changing a shared memory flag to
stop the go() function.

Pipes not being concurrently bi-directional appears to be a design
flaw to me.
pyCSP appears to be an interesting approach, but it does not support
communication across O.S. processes on Win32.

== 2 of 3 ==
Date: Tues, Mar 2 2010 6:11 pm
From: Metalone

Well, I just realized that I could use a separate pipe to send the
result back. This might work ok.

== 3 of 3 ==
Date: Tues, Mar 2 2010 6:37 pm
From: MRAB

Metalone wrote:
> Well, I just realized that I could use a separate pipe to send the
> result back. This might work ok.

Or you could call .poll on the pipe and sleep if there's no input yet.

==============================================================================
TOPIC: Draft PEP on RSON configuration file format
http://groups.google.com/group/comp.lang.python/t/09ce33197b330e90?hl=en
==============================================================================

== 1 of 6 ==
Date: Tues, Mar 2 2010 6:26 pm
From: Patrick Maupin

On Mar 2, 5:36 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
> You seem to be taking the position that if you start with a config file
> config.json, it is "too hard to edit", but then by renaming it to
> config.rson it magically becomes easier to edit. That *is* ludicrous.

No, but that seems to be the position you keep trying to ascribe to
me: "Wait a minute... if JSON is too hard to edit, and RSON is a
*superset* of JSON, that means by definition every JSON file is also a
valid RSON file. Since JSON is too hard to manually edit, so is
RSON."

> Perhaps what you mean to say is that JSON *can be* (not is) too hard to
> edit, and RSON *can be* too hard to edit too, but RSON has additional
> benefits, including being easier to edit *sometimes*.

I have said as much, in multiple prior postings on this thread, if you
care to look.

> So far you have done (in my opinion) a really poor job of explaining what
> those benefits are.

That's certainly a valid complaint, and I can certainly believe that's
true (and I'm going to be working on the doc some more), but instead
of making this complaint, you made the (still silly IMO) assertion
that a superset has to be as unreadable as the base set.

> You've bad-mouthed existing config formats, then
> tried to convince us that RSON is almost exactly the same as one of those formats apart from a couple of trivial changes of spelling (True for true, etc.).

This is conflating two different issues. In a lame attempt to show
the silliness of the argument that the superset must be as bad as the
subset, I was trying to explain that, if you make a very few changes,
Python is a superset of JSON. However, my lame attempt at this was
obviously as poorly thought out as some of the rest of my words,
because it started an additional discussion that wasn't really germane
to the real issues about configuration files.

> In my opinion, if you're going to get any traction with RSON, you need to
> demonstrate some examples of where JSON actually is hard to write, and
> show how RSON makes it easier. It's not good enough showing badly written
> JSON, it has to be examples that can't be written less badly given the
> constraints of JSON.

Agreed, and I will be working on that.

Best regards,
Pat

== 2 of 6 ==
Date: Tues, Mar 2 2010 6:54 pm
From: "Alf P. Steinbach"

* Patrick Maupin:
> On Mar 2, 5:36 pm, Steven D'Aprano <st...@REMOVE-THIS-
> cybersource.com.au> wrote:
>> You seem to be taking the position that if you start with a config file
>> config.json, it is "too hard to edit", but then by renaming it to
>> config.rson it magically becomes easier to edit. That *is* ludicrous.
>
> No, but that seems to be the position you keep trying to ascribe to
> me: "Wait a minute... if JSON is too hard to edit, and RSON is a
> *superset* of JSON, that means by definition every JSON file is also a
> valid RSON file. Since JSON is too hard to manually edit, so is
> RSON."

Just a heads-up: IME it's next to impossible (maybe actually impossible) to
convince Steven that your position is not the one he ascribes to you. At least
not without an extremely lengthy debate veering off on multiple similar tangents
plus some that one would never dream of. So I'd give up on that.

Anyway, I agree with the sentiments expressed by many in this thread that what's
important is the established "eco-culture", not the editability.

Thus, even though XML isn't all that editable it's what I'd choose by default
for rich configuration information, regardless of whether some simpler to edit
alternative existed. Simply because there are so many XML tools out there, and
people know about XML. It's like MS-DOS once became popular in spite of being
extremely technically imperfect for its purpose, and then Windows... :-)

Cheers,

- Alf

== 3 of 6 ==
Date: Tues, Mar 2 2010 7:20 pm
From: Erik Max Francis

Patrick Maupin wrote:
> On Mar 2, 5:36 pm, Steven D'Aprano <st...@REMOVE-THIS-
> cybersource.com.au> wrote:
>> You seem to be taking the position that if you start with a config file
>> config.json, it is "too hard to edit", but then by renaming it to
>> config.rson it magically becomes easier to edit. That *is* ludicrous.
>
> No, but that seems to be the position you keep trying to ascribe to
> me: "Wait a minute... if JSON is too hard to edit, and RSON is a
> *superset* of JSON, that means by definition every JSON file is also a
> valid RSON file. Since JSON is too hard to manually edit, so is
> RSON."

Huh? That's the argument being used against you, not the argument being
ascribed to you. You're getting confused about something, somewhere.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
I wonder if heaven got a ghetto
-- Tupac Shakur

== 4 of 6 ==
Date: Tues, Mar 2 2010 7:35 pm
From: Patrick Maupin

On Mar 2, 9:20 pm, Erik Max Francis <m...@alcyone.com> wrote:
> Patrick Maupin wrote:
> > On Mar 2, 5:36 pm, Steven D'Aprano <st...@REMOVE-THIS-
> > cybersource.com.au> wrote:
> >> You seem to be taking the position that if you start with a config file
> >> config.json, it is "too hard to edit", but then by renaming it to
> >> config.rson it magically becomes easier to edit. That *is* ludicrous.
>
> > No, but that seems to be the position you keep trying to ascribe to
> > me: "Wait a minute... if JSON is too hard to edit, and RSON is a
> > *superset* of JSON, that means by definition every JSON file is also a
> > valid RSON file. Since JSON is too hard to manually edit, so is
> > RSON."
>
> Huh? That's the argument being used against you, not the argument being
> ascribed to you. You're getting confused about something, somewhere.
>
> --
> Erik Max Francis && m...@alcyone.com &&http://www.alcyone.com/max/
> San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
> I wonder if heaven got a ghetto
> -- Tupac Shakur

Yes, it is very confusing. Steven used that purported argument
against me, and then since I disagreed with it, it apparently meant
that I was arguing that changing the file extension type (which I've
never even proposed or discussed, btw) from json to rson somehow
magically makes a preexisting file all better. I have a headache now,
and it will only get worse, so that's really all I have left to say
about this issue.

Best regards,
Pat

== 5 of 6 ==
Date: Tues, Mar 2 2010 9:00 pm
From: Steven D'Aprano

On Tue, 02 Mar 2010 19:35:20 -0800, Patrick Maupin wrote:

> Yes, it is very confusing. Steven used that purported argument against
> me, and then since I disagreed with it, it apparently meant that I was
> arguing that changing the file extension type (which I've never even
> proposed or discussed, btw) from json to rson

My argument is *figurative*, not literal.

> somehow magically makes a preexisting file all better.

You might not have intended that ludicrous conclusion, but it was implied
by some of your posts, particularly the early ones. Of course I don't
think that you *actually* believe the conclusion.

I believe that, whatever the real or imagined benefit of RSON over JSON,
in this thread you have attempted to over-sell RSON while giving
relatively little justification for it.

I wish you every success in your project, but think that it is off-topic
for a Python discussion group.

--
Steven

== 6 of 6 ==
Date: Tues, Mar 2 2010 9:36 pm
From: Erik Max Francis

Patrick Maupin wrote:
> On Mar 2, 9:20 pm, Erik Max Francis <m...@alcyone.com> wrote:
>> Patrick Maupin wrote:
>>> On Mar 2, 5:36 pm, Steven D'Aprano <st...@REMOVE-THIS-
>>> cybersource.com.au> wrote:
>>>> You seem to be taking the position that if you start with a config file
>>>> config.json, it is "too hard to edit", but then by renaming it to
>>>> config.rson it magically becomes easier to edit. That *is* ludicrous.
>>> No, but that seems to be the position you keep trying to ascribe to
>>> me: "Wait a minute... if JSON is too hard to edit, and RSON is a
>>> *superset* of JSON, that means by definition every JSON file is also a
>>> valid RSON file. Since JSON is too hard to manually edit, so is
>>> RSON."
>> Huh? That's the argument being used against you, not the argument being
>> ascribed to you. You're getting confused about something, somewhere.
>
> Yes, it is very confusing. Steven used that purported argument
> against me, and then since I disagreed with it, it apparently meant
> that I was arguing that changing the file extension type (which I've
> never even proposed or discussed, btw) from json to rson somehow
> magically makes a preexisting file all better.

No, that was not the point he was making. You should reread more
carefully (and be aware of sarcasm).

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
Perfect situations must go wrong
-- Florence, _Chess_

==============================================================================
TOPIC: Challenge: escape from the pysandbox
http://groups.google.com/group/comp.lang.python/t/87bf10f8acede7c3?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 6:37 pm
From: Victor Stinner

Le dimanche 28 février 2010 23:40:59, Daniel Fetchinson a écrit :
> >>I guess they also have some kind of a sandbox if they let people run
> >>python on their machines, I'm not sure if it's open source though.
> >
> > Thing is, I'm sure that Google uses a critical backstop to any
> > Python-based sandbox: something like a chroot jail. The Python sandbox
> > is mostly there to inform you about what you can and can't do; the real
> > security is provided by the OS.
>
> I see, makes perfect sense. This then raises the question whether it's
> important to have a 100% fool proof python sandbox without help from
> the OS, or this goal is not only too ambitious but also not really a
> useful one.

This is just impossible :-) PHP tried that but it's too hard to write an
exhaustive blacklist because too much code have to be modified. If you require
a 100% fool proof sandbox, you have to use a sandbox between the Python
process and the OS (and not inside the Python process).

> One aspect might be that one might want to have a platform
> independent way of sandboxing, perhaps.

The problem have to be splitted in two parts: protect access to OS resources
(files, network, etc.) and protect access to Python objects (eg. create a read
only view of objects injected to the sandbox).

An "OS sandbox" can not protect objects inside the Python object. And
pysandbox cannot protect all access to OS resources (but I try to do that
:-)).

pysandbox is a possible solution to the second problem: control Python object
space.
--
Victor Stinner
http://www.haypocalc.com/

== 2 of 2 ==
Date: Tues, Mar 2 2010 6:42 pm
From: Victor Stinner

Le dimanche 28 février 2010 17:43:07, Victor Stinner a écrit :
> Yes, Google AppEngine has its Python sandbox and the source code is
> available online. I don't know the license. I found 7 vulnerabilities in 1
> hour :-) I contacted Google security team. (...) There are other
> differences, but I prefer to wait for the answer from
> Google before telling you more :)

Google answered me. I misunderstood AppEngine sandbox. It's not a Python
sandbox.

AppEngine sandbox is just a tool helping developers to test programs without
the "real" (OS) sandbox. Their Python sandbox *emulates* the real sandbox, and
so it's completly different to pysandbox.

--
Victor Stinner
http://www.haypocalc.com/

==============================================================================
TOPIC: Python 2.6.5 release candidate 1 now available
http://groups.google.com/group/comp.lang.python/t/cbc186385291232f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:17 pm
From: Barry Warsaw

Hello everyone,

The source tarballs and Windows installer for Python 2.6.5 release candidate 1
are now available:

http://www.python.org/download/releases/2.6.5/

Please download them, install them, and try to use them with your favorite
projects and environments. If no regressions are found, we will do the final
release on Monday March 15, 2010. Please test the release candidate as
much as possible in the meantime, and help make 2.6.5 a rock solid release!

Thanks,
-Barry

P.S. The Mac installer will hopefully be available soon.

==============================================================================
TOPIC: Is this secure?
http://groups.google.com/group/comp.lang.python/t/ffff2b290db4e811?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:51 pm
From: Lie Ryan

On 02/25/2010 06:16 AM, mk wrote:
> On 2010-02-24 20:01, Robert Kern wrote:
>> I will repeat my advice to just use random.SystemRandom.choice() instead
>> of trying to interpret the bytes from /dev/urandom directly.
>
> Out of curiosity:
>
> def gen_rand_string(length):
> prng = random.SystemRandom()
> chars = []
> for i in range(length):
> chars.append(prng.choice('abcdefghijklmnopqrstuvwxyz'))
> return ''.join(chars)
>
> if __name__ == "__main__":
> chardict = {}
> for i in range(10000):
> ## w = gen_rand_word(10)
> w = gen_rand_string(10)
> count_chars(chardict, w)
> counts = list(chardict.items())
> counts.sort(key = operator.itemgetter(1), reverse = True)
> for char, count in counts:
> print char, count
>
>
> s 3966
> d 3912
> g 3909
> h 3905
> a 3901
> u 3900
> q 3891
> m 3888
> k 3884
> b 3878
> x 3875
> v 3867
> w 3864
> y 3851
> l 3825
> z 3821
> c 3819
> e 3819
> r 3816
> n 3808
> o 3797
> f 3795
> t 3784
> p 3765
> j 3730
> i 3704
>
> Better, although still not perfect.
>

I give you this:

import itertools
def gen():
valid_chars = 'abcdefghijklmnopqrstuvwxyz'
for char in itertools.repeat(valid_chars):
yield char

gen = gen()
def gen_rand_string(length):
chars = (next(gen) for i in range(length))
return ''.join(chars)

since it gives me a perfect distribution of letters, it must be a very
secure random password generation scheme.

==============================================================================
TOPIC: cpan for python?
http://groups.google.com/group/comp.lang.python/t/ecd51ced8d24593e?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Mar 2 2010 7:59 pm
From: Lie Ryan

On 03/03/2010 09:47 AM, TomF wrote:
> On 2010-03-02 13:14:50 -0800, R Fritz <rfritz@u.washington.edu> said:
>
>> On 2010-02-28 06:31:56 -0800, ssteinerX@gmail.com said:
>>>
>>> On Feb 28, 2010, at 9:28 AM, Someone Something wrote:
>>>
>>>> Is there something like cpan for python? I like python's syntax, but
>>>> Iuse perl because of cpan and the tremendous modules that it has. --
>>>
>>> Please search the mailing list archives.
>>>
>>> This subject has been discussed to absolute death.
>>
>> But somehow the question is not in the FAQ, though the answer is. See:
>>
>> <http://www.python.org/doc/faq/library/#how-do-i-find-a-module-or-application-to-perform-task-x>
>>
>
> There
> is also a program called cpan, distributed with Perl. It is used for
> searching, downloading, installing and testing modules from the CPAN
> repository. It's far more extensive than setuptools. AFAIK the python
> community has developed nothing like it.

python have easy_install

== 2 of 3 ==
Date: Tues, Mar 2 2010 8:58 pm
From: John Bokma

Lie Ryan <lie.1296@gmail.com> writes:

> On 03/03/2010 09:47 AM, TomF wrote:

[..]

>> There
>> is also a program called cpan, distributed with Perl. It is used for
>> searching, downloading, installing and testing modules from the CPAN
>> repository. It's far more extensive than setuptools. AFAIK the python
>> community has developed nothing like it.
>
> python have easy_install

How easy is it to /remove/ something? ;-) (Last time I checked I read
something like "manually remove the .egg"...

--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

== 3 of 3 ==
Date: Tues, Mar 2 2010 9:17 pm
From: Ben Finney

Lie Ryan <lie.1296@gmail.com> writes:

> On 03/03/2010 09:47 AM, TomF wrote:
> > There is also a program called cpan, distributed with Perl. It is
> > used for searching, downloading, installing and testing modules from
> > the CPAN repository. It's far more extensive than setuptools. AFAIK
> > the python community has developed nothing like it.
>
> python have easy_install

Indeed. And that program is nothing like the Perl 'cpan' program.

--
\ "Value your freedom or you will lose it, teaches history. |
`\ "Don't bother us with politics," respond those who don't want |
_o__) to learn." —Richard Stallman, 2002 |
Ben Finney

==============================================================================
TOPIC: Docstrings considered too complicated
http://groups.google.com/group/comp.lang.python/t/dea5c94f3d058e26?hl=en
==============================================================================

== 1 of 4 ==
Date: Tues, Mar 2 2010 9:18 pm
From: Gregory Ewing

MRAB wrote:

> BTW, the first programming I did was in hexadecimal (C4xx was "LDI xx").

Hey, a SC/MP! That was my first programming language,
too. What sort of machine was it in?

--
Greg

== 2 of 4 ==
Date: Tues, Mar 2 2010 9:30 pm
From: Gregory Ewing

Grant Edwards wrote:

> Just a mediocre copy of the CP/M filesystem, which was in turn
> copied from DEC's RSTS or RSX.

It was actually an improvement over CP/M's file
system. CP/M didn't have hierarchical directories
or timestamps and recorded file sizes in 128-byte
blocks rather than bytes.

--
Greg

== 3 of 4 ==
Date: Tues, Mar 2 2010 9:40 pm
From: Gregory Ewing

Ben Finney wrote:

> Just as customers should demand both that a building be built to do its
> job well, *and* that its architectural plans meet measurable, testable
> industry standards of quality for independent re-use at some
> indeterminate later date.

A problem is that it's very hard to come up with
*measurable* standards of code quality.

There's no equivalent in the software world of
specifying a grade of steel or type of sand.
The things that really matter are all subjective.

--
Greg

== 4 of 4 ==
Date: Tues, Mar 2 2010 9:48 pm
From: Steven D'Aprano

On Wed, 03 Mar 2010 18:40:00 +1300, Gregory Ewing wrote:

> Ben Finney wrote:
>
>> Just as customers should demand both that a building be built to do its
>> job well, *and* that its architectural plans meet measurable, testable
>> industry standards of quality for independent re-use at some
>> indeterminate later date.
>
> A problem is that it's very hard to come up with *measurable* standards
> of code quality.
>
> There's no equivalent in the software world of specifying a grade of
> steel or type of sand. The things that really matter are all subjective.

True, but one can look at "best practice", or even "standard practice".
For Python coders, using docstrings is standard practice if not best
practice. Using strings as comments is not.

Or one can simply use *reason*: what justification is there for putting
comments in strings at the top of the function? The only one I can see is
if you are writing for an embedded device, you may want to remove doc
strings to save memory -- and even that is implementation dependent.

What justification is there for putting docstrings in functions? Code
becomes self-documenting, you can run Python tools that extract and run
doctests, standard tools in the standard library work, other coders will
immediately understand what you have done, and (unlike the behaviour of
string-comments) the behaviour of docstrings is guaranteed by the
language.

Unless you are writing for an embedded devise, there is NO objective
reason for putting comments in strings above the function, and MANY
objective reasons for putting them into docstrings. Okay, this isn't
quite the same as measuring the strength of concrete under compression,
but it's not a subjective choice like "tea or coffee?".

--
Steven

==============================================================================
TOPIC: case do problem
http://groups.google.com/group/comp.lang.python/t/d73f6f6a59d3bbfd?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 10:23 pm
From: Gregory Ewing

Alf P. Steinbach wrote:
> * Tracubik:
>
>> iterations=0;
>> count=0;
>> REPEAT;
>> iterations = iterations+1;
>> ...
>> IF (genericCondition) THEN count=count+1;
>> ...
>> CASE count OF:
>> 1: m = 1
>> 2: m = 10
>> 3: m = 100
>
> Uhm, is this syntactically valid Pascal? As I recall, every Pascal
> construct was delimited in some way.

I think it's okay. Pascal's control structures such as
if-then and while-do mostly take single statements and
didn't have an ending keyword. If you want multiple
statements in the body you have to put begin-end around
them.

Putting a semicolon after REPEAT is stylistically a
bit odd, but it's not wrong.

--
Greg

==============================================================================
TOPIC: Need bluez/python ( PyBluez) method to access BlueZ data- Please Help!
http://groups.google.com/group/comp.lang.python/t/96ccf3081b502537?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 10:18 pm
From: "Isaac"

Hi,

I need to access data that is handled and stored in the BlueZ file system,
but is, unfortunately, not available via the current BlueZ D-Bus API.

That is, the data I need is parsed by BlueZ, but not provided in the current
D-Bus signal.

I need a method or interface that does not rely on the D-Bus API and can
directly access the BlueZ file system to get this parsed data.

Can PyBlueZ do this? If not, any suggestions would be immensely appreciated.

Thanks!
Isaac

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.python"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.python?hl=en

To unsubscribe from this group, send email to comp.lang.python+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.python/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Tuesday, March 2, 2010

comp.lang.python - 25 new messages in 11 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts