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

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

comp.lang.python@googlegroups.com

Today's topics:

==============================================================================
TOPIC: expy 0.5.2 released
http://groups.google.com/group/comp.lang.python/t/ea3018487d9365ec?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 2 2010 10:43 pm
From: Yingjie Lan

Hi,

expy is an expressway to extend python.

in release 0.5.2, expy now supports custom exceptions, besides all built-in ones, and exception handling is made easy.

for more info, see

http://expy.sourceforge.net/

cheers,

Yingjie

==============================================================================
TOPIC: simple and fast platform independent IPC
http://groups.google.com/group/comp.lang.python/t/0fb9d731abbc5ab3?hl=en
==============================================================================

== 1 of 9 ==
Date: Wed, Feb 3 2010 12:32 am
From: News123

Hi,

I wondered what IPC library might be best simplest for following task?

I'm having a few python scripts all running on the same host (linux or
win), which are started manually in random order. (no common parent process)
Each process might be identified by an integer (1,2,3) or by a symbolic
name ( 'dad' , 'mom' , 'dog' )

these scripts want to send short messages to each other ( mostly
integers, max a few bytes, short string), which would be enqueued in
message queues of the receiving process.

example:

'dad' wants to tell 'mom': 'cook'
'dog' wants to tell 'dad' : 'feedme'
'mom' wants to tell 'dad' : 'cookyourself'

the receiver dos not necesarily have to know who sent the message

a message shall be dropped silently if the receiving process is not running

a message shall be reliably delivered if the receiving process is up

xmlrpc seems to be a little heavy for such tasks.

signals don't allow to exchange data

a shared memory message queue would probably a good solution, but
python's Multiprocessing.Queue seems to require a common parent process

thanks a lot for any ideas / suggestions

== 2 of 9 ==
Date: Wed, Feb 3 2010 1:29 am
From: "Gabriel Genellina"

En Wed, 03 Feb 2010 05:32:58 -0300, News123 <news123@free.fr> escribi�:

> I'm having a few python scripts all running on the same host (linux or
> win), which are started manually in random order. (no common parent
> process)
> Each process might be identified by an integer (1,2,3) or by a symbolic
> name ( 'dad' , 'mom' , 'dog' )
>
> these scripts want to send short messages to each other ( mostly
> integers, max a few bytes, short string), which would be enqueued in
> message queues of the receiving process.
>
> example:
>
> 'dad' wants to tell 'mom': 'cook'
> 'dog' wants to tell 'dad' : 'feedme'
> 'mom' wants to tell 'dad' : 'cookyourself'

Try using a named pipe between each pair of processes (os.mkfifo + open on
Linux, open(r"\\.\pipe\desired_name", ...) on Windows)

--
Gabriel Genellina

== 3 of 9 ==
Date: Wed, Feb 3 2010 1:34 am
From: Vinay Sajip

On Feb 3, 8:32 am, News123 <news...@free.fr> wrote:
> Hi,
>
> I wondered what IPC library might be best simplest for following task?
>
> I'm having a few python scripts all running on the same host (linux or
> win), which are started manually in random order. (no common parent process)
> Each process might be identified by an integer (1,2,3) or by a symbolic
> name ( 'dad' , 'mom' , 'dog' )
>
> these scripts want to send short messages to each other ( mostly
> integers, max a few bytes, short string), which would be enqueued in
> message queues of the receiving process.
>
> example:
>
> 'dad' wants to tell 'mom': 'cook'
> 'dog' wants to tell 'dad' : 'feedme'
> 'mom' wants to tell 'dad' : 'cookyourself'
>
> the receiver dos not necesarily have to know who sent the message
>
> a message shall be dropped silently if the receiving process is not running
>
> a message shall be reliably delivered if the receiving process is up
>
> xmlrpc seems to be a little heavy for such tasks.
>
> signals don't allow to exchange data
>
> a shared memory message queue would probably a good solution, but
> python's Multiprocessing.Queue seems to require a common parent process
>
> thanks a lot for any ideas / suggestions
>
> N
>
> N

Gabriel's suggestion is very good; if you need something which is a
little more like RPC but still quite lightweight, consider Pyro
(http://pyro.sourceforge.net/)

Regards,

Vinay Sajip

== 4 of 9 ==
Date: Wed, Feb 3 2010 2:39 am
From: Joan Miller

On 3 feb, 09:34, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
> On Feb 3, 8:32 am, News123 <news...@free.fr> wrote:
>
>
>
> > Hi,
>
> > I wondered what IPC library might be best simplest for following task?
>
> > I'm having a few python scripts all running on the same host (linux or
> > win), which are started manually in random order. (no common parent process)
> > Each process might be identified by an integer (1,2,3) or by a symbolic
> > name ( 'dad' , 'mom' , 'dog' )
>
> > these scripts want to send short messages to each other ( mostly
> > integers, max a few bytes, short string), which would be enqueued in
> > message queues of the receiving process.
>
> > example:
>
> > 'dad' wants to tell 'mom': 'cook'
> > 'dog' wants to tell 'dad' : 'feedme'
> > 'mom' wants to tell 'dad' : 'cookyourself'
>
> > the receiver dos not necesarily have to know who sent the message
>
> > a message shall be dropped silently if the receiving process is not running
>
> > a message shall be reliably delivered if the receiving process is up
>
> > xmlrpc seems to be a little heavy for such tasks.
>
> > signals don't allow to exchange data
>
> > a shared memory message queue would probably a good solution, but
> > python's Multiprocessing.Queue seems to require a common parent process
>
> > thanks a lot for any ideas / suggestions
>
> > N
>
> > N
>
> Gabriel's suggestion is very good; if you need something which is a
> little more like RPC but still quite lightweight, consider Pyro
> (http://pyro.sourceforge.net/)
>
> Regards,
>
> Vinay Sajip

I've read that Pyro is not safe. Anyway, you have in mind that respect
to speed:

shared memory > named pipes > Unix domain socket > TCP socket

I don't sure about if the message queues would be faster that Unix
domain sockets

Another thing. Using shared memory would be as to use a single thread
but using message queues would be as multiple-threading.

== 5 of 9 ==
Date: Wed, Feb 3 2010 2:46 am
From: News123

Hi Gabriel,

I'll look at it.
I wasn't aware about named pipes for windows.

bye

Gabriel Genellina wrote:
> En Wed, 03 Feb 2010 05:32:58 -0300, News123 <news123@free.fr> escribió:
>
>> I'm having a few python scripts all running on the same host (linux or
>> win), which are started manually in random order. (no common parent
>> process)
>> Each process might be identified by an integer (1,2,3) or by a symbolic
>> name ( 'dad' , 'mom' , 'dog' )
>>
>> these scripts want to send short messages to each other ( mostly
>> integers, max a few bytes, short string), which would be enqueued in
>> message queues of the receiving process.
>>
>> example:
>>
>> 'dad' wants to tell 'mom': 'cook'
>> 'dog' wants to tell 'dad' : 'feedme'
>> 'mom' wants to tell 'dad' : 'cookyourself'
>
> Try using a named pipe between each pair of processes (os.mkfifo + open
> on Linux, open(r"\\.\pipe\desired_name", ...) on Windows)
>

== 6 of 9 ==
Date: Wed, Feb 3 2010 2:54 am
From: Tim Golden

[News123<news...@free.fr>]
>>> I wondered what IPC library might be best simplest for following task?

...

>>> xmlrpc seems to be a little heavy for such tasks.
>>
>>> signals don't allow to exchange data
>>
>>> a shared memory message queue would probably a good solution, but
>>> python's Multiprocessing.Queue seems to require a common parent process

[Vinay Sajip]
>> Gabriel's suggestion is very good; if you need something which is a
>> little more like RPC but still quite lightweight, consider Pyro
>> (http://pyro.sourceforge.net/)

[peloko45@gmail.com]
> I've read that Pyro is not safe.

That's a fairly broad thing to say. I've read lots
of things. What does "is not safe" mean, in any case?
I assume you've got a valid concern in mind which is
worth passing on to a would-be user, but what exactly
is it? FWIW I've used Pyro on and off over the years
without any problems. Certainly my computer's never
blown up as a result of using it.

Obviously Pyro is Python-only so interaction with non-Python
code would be problematic. But the OP only mentions Python
scripts so hopefully that wouldn't be an issue...

>Anyway, you have in mind that respect to speed:
>
> shared memory> named pipes> Unix domain socket> TCP socket

True, but the OP didn't mention speed; rather simplicity. Not
saying it isn't a consideration but premature optimisation and
all that...

> Another thing. Using shared memory would be as to use a single thread
> but using message queues would be as multiple-threading.

And therefore...?

I think you need to make your points more clearly.

TJG

== 7 of 9 ==
Date: Wed, Feb 3 2010 3:05 am
From: Eden Kirin

On 03.02.2010 09:32, News123 wrote:
> Hi,
>
> I wondered what IPC library might be best simplest for following task?

Consider using Thrift (http://incubator.apache.org/thrift/). It is
multiplatform multilanguage RPC and IPC solution. I implemented it in
couple of my projects and it works seamlessly.

--
www.vikendi.net -/- www.supergrupa.com

== 8 of 9 ==
Date: Wed, Feb 3 2010 3:31 am
From: Joan Miller

On 3 feb, 10:54, Tim Golden <m...@timgolden.me.uk> wrote:
> [News123<news...@free.fr>]
>
> >>> I wondered what IPC library might be best simplest for following task?
>
> ...
>
> >>> xmlrpc seems to be a little heavy for such tasks.
>
> >>> signals don't allow to exchange data
>
> >>> a shared memory message queue would probably a good solution, but
> >>> python's Multiprocessing.Queue seems to require a common parent process
>
> [Vinay Sajip]
>
> >> Gabriel's suggestion is very good; if you need something which is a
> >> little more like RPC but still quite lightweight, consider Pyro
> >> (http://pyro.sourceforge.net/)
>
> [pelok...@gmail.com]
>
> > I've read that Pyro is not safe.
>
> That's a fairly broad thing to say. I've read lots
> of things. What does "is not safe" mean, in any case?
> I assume you've got a valid concern in mind which is
> worth passing on to a would-be user, but what exactly
> is it? FWIW I've used Pyro on and off over the years
> without any problems. Certainly my computer's never
> blown up as a result of using it.
From its own page:
"Pyro has never been truly designed to provide a secure communication
mechanism, nor has it had a security review or -test by a security
expert."
http://pyro.sourceforge.net/features.html

> Obviously Pyro is Python-only so interaction with non-Python
> code would be problematic. But the OP only mentions Python
> scripts so hopefully that wouldn't be an issue...

== 9 of 9 ==
Date: Wed, Feb 3 2010 5:04 am
From: Paul Rubin

News123 <news123@free.fr> writes:
> I'm having a few python scripts all running on the same host (linux or
> win), which are started manually in random order. (no common parent process)
> Each process might be identified by an integer (1,2,3) or by a symbolic
> name ( 'dad' , 'mom' , 'dog' )

If they are running on the same host with no untrusted local users, you
can use unix-domain sockets instead of TCP sockets and then the server
should be unreachable from the internet. Then you're less exposed to
possible security issues with libraries like Pyro. Personally I've just
used SocketServer/SimpleHTTPServer on the listening side and simplejson
for serialization, but that was for low-rent, low-performance
applications. If you want something faster, zeromq (www.zeromq.org)
looks interesting.

==============================================================================
TOPIC: Logging oddity: handlers mandatory in every single logger?
http://groups.google.com/group/comp.lang.python/t/c4da89f2c43b0bc8?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Feb 3 2010 12:50 am
From: Masklinn

On 2 Feb 2010, at 17:52 , Jean-Michel Pichavant wrote:
>
> Masklinn wrote:
>> Jean-Michel Pichavant wrote:
>>
>>> To add a custom level, I would proceed that way:
>>>
>>> logging.ALERT = 45
>>> logging.addLevelName(logging.ALERT, 'ALERT !!')
>>> logging.getLogger().log(logging.ALERT, 'test')
>>>
>>> Passing a string to the log method as you did is incorrect.
>>>
>>
>> I know it's currently incorrect. My point was more along the line that there was *no reason* for it to be incorrect. logging already contains all the tools for log('PANTS_ON_FIRE') to be allowed
>>
> The reason is that log takes an *int* as first argument that defines the logging level. You gave a string. So There is definitely a reason for it to be incorrect.
That's not a reason, that's just what currently happens. I know it doesn't work, and I know why, I went and checked the code. But there's no fundamental reason why you couldn't use a level *name* instead of a level code. And indeed, in most parts of logging you can (including but not limited to the configuration of handlers and loggers)

>>
>>> Regarding your first point, I guess it's anti pattern. One way to do it:
>>> 1/ Configure the root logger with the lowest value 0, so the root logger does not filter any level.
>>> 2/ Configure each of your logger with the correct level
>>>
>>> That way you can configure your '0' logger as you (badly :o)) named it with one level, and configure a potential '1' logger with another level. Don't bother with propagation. That way you won't need to duplicate your handlers on every logger.
>>>
>>
>> re logger 0, no need for complex name for a test case (and it allowed me to create easy-to-remember 0.1 and 0.1.2 if needed)
>>
>> Re your answer, from what I understand you want the root logger to NOTSET and then each child logger with its correct level? But that's not a solution, each and every level will *still* require a handler explicitly configured on it. That's in fact very much my issue: logging refuses that a logger be handler-less in a config file, it's mandatory to configure a handler any time a logger is configured.
>>
> the field handlers must be defined even if empty.
Ah, interesting, I didn't think it could be defined as empty.

Which makes the requirement to have an empty ``handler`` completely nonsensical, doesn't it?

== 2 of 4 ==
Date: Wed, Feb 3 2010 2:50 am
From: Jean-Michel Pichavant

>> The reason is that log takes an *int* as first argument that defines the logging level. You gave a string. So There is definitely a reason for it to be incorrect.
>>
> That's not a reason, that's just what currently happens. I know it doesn't work, and I know why, I went and checked the code. But there's no fundamental reason why you couldn't use a level *name* instead of a level code. And indeed, in most parts of logging you can (including but not limited to the configuration of handlers and loggers)
>
>
You don't neeed to check the code for that ! It is written in the
documentation. The logging module designer choose to ask for a level,
not a level name, possibly because 2 different levels can have the same
name.

>>
>> the field handlers must be defined even if empty.
>>
> Ah, interesting, I didn't think it could be defined as empty.
>
> Which makes the requirement to have an empty ``handler`` completely nonsensical, doesn't it?
>
>

'completeley nonsensical' is overstating. It make sense to state that
your handler list is empty, when it is empty. Having no field at all
could possibly mean the same, but it's often better that have one
consisten way to interface with a module.

== 3 of 4 ==
Date: Wed, Feb 3 2010 3:36 am
From: Masklinn

On 3 Feb 2010, at 11:50 , Jean-Michel Pichavant wrote:
>
>
>>> The reason is that log takes an *int* as first argument that defines the logging level. You gave a string. So There is definitely a reason for it to be incorrect.
>>>
>> That's not a reason, that's just what currently happens. I know it doesn't work, and I know why, I went and checked the code. But there's no fundamental reason why you couldn't use a level *name* instead of a level code. And indeed, in most parts of logging you can (including but not limited to the configuration of handlers and loggers)
>>
> You don't neeed to check the code for that ! It is written in the documentation. The logging module designer choose to ask for a level, not a level name, possibly because 2 different levels can have the same name.
>
Nope, 2 different levels cannot have the same name: levels are currently stored in a dict of string:level and level:string, so you can't have 2 names for the same level, and you can't have 2 levels with the same name either.

>>>
>>> the field handlers must be defined even if empty.
>>>
>> Ah, interesting, I didn't think it could be defined as empty.
>>
>> Which makes the requirement to have an empty ``handler`` completely nonsensical, doesn't it?
> 'completeley nonsensical' is overstating. It make sense to state that your handler list is empty, when it is empty.
Programmatically, that's implied in the fact that you aren't specifying it. Why wouldn't it be in the config file? Why the asymetry here?

== 4 of 4 ==
Date: Wed, Feb 3 2010 5:32 am
From: Jean-Michel Pichavant

Masklinn wrote:
> On 3 Feb 2010, at 11:50 , Jean-Michel Pichavant wrote:
>
>> You don't neeed to check the code for that ! It is written in the documentation. The logging module designer choose to ask for a level, not a level name, possibly because 2 different levels can have the same name.
>>
>>
> Nope, 2 different levels cannot have the same name: levels are currently stored in a dict of string:level and level:string, so you can't have 2 names for the same level, and you can't have 2 levels with the same name either.
>
>
import logging
logging.addLevelName(5, 'test')
logging.addLevelName(6, 'test')

logging._levelNames
{0: 'NOTSET',
5: 'test',
6: 'test',
10: 'DEBUG',
20: 'INFO',
30: 'WARNING',
40: 'ERROR',
50: 'CRITICAL',
'CRITICAL': 50,
'DEBUG': 10,
'ERROR': 40,
'INFO': 20,
'NOTSET': 0,
'WARN': 30,
'WARNING': 30,
'test': 6}

now quoting the doc:

logging.addLevelName(/lvl/, /levelName/)
Associates level /lvl/ with text /levelName/ in an internal
dictionary, which is *used to map numeric levels to a textual
representation*, for example when a Formatter
<http://docs.python.org/library/logging.html#logging.Formatter>
formats a message. This function can also be used to define your own
levels. The only constraints are that all levels used must be
registered using this function, levels should be positive integers
and they should increase in increasing order of severity.

int -> string is the public association
string- > int is an internal hack to map easilty map Level name to their
int identifier. This is used for the config file, where you specify a
string not an int (you vrite level=DEBUG, not level=10)

Look at the builtin WARNING & WARN level, two different names for the
same level.

In any case, you have to trust the documentation and public interface
signature. Introspecting the code can be misleading. Now I better
understand your initial concern.

>>>> the field handlers must be defined even if empty.
>>>>
>>>>
>>> Ah, interesting, I didn't think it could be defined as empty.
>>>
>>> Which makes the requirement to have an empty ``handler`` completely nonsensical, doesn't it?
>>>
>> 'completeley nonsensical' is overstating. It make sense to state that your handler list is empty, when it is empty.
>>
> Programmatically, that's implied in the fact that you aren't specifying it. Why wouldn't it be in the config file? Why the asymetry here?
>
>
Note how progammatically the list of handlers is set to an empty list.
The attribute handlers is always set, so the config file field shall be :o)

In [11]: logger = logging.getLogger('test')

In [12]: logger.handlers
Out[12]: []

==============================================================================
TOPIC: Python and Ruby
http://groups.google.com/group/comp.lang.python/t/dfe4f6c60032755e?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 1:21 am
From: "Timothy N. Tsvetkov"

On Jan 28, 2:29 am, Jonathan Gardner <jgard...@jonathangardner.net>
wrote:
> On Jan 27, 5:47 am, Simon Brunning <si...@brunningonline.net> wrote:
>
>
>
> > I think Python is a little cleaner, but I'm sure you'd find Ruby fans
> > who'd argue the complete opposite.
>
> Are you sure about that?
>
> There's a lot of line noise in Ruby. How are you supposed to pronounce
> "@@"? What about "{|..| ... }"?
>
> There's a lot of "magic" in Ruby as well. For instance, function calls
> are made without parentheses. Blocks can only appear as the first
> argument. There's a lot more, if you put your mind to it.
>
> Indentation is also optional in Ruby. You can quickly fool a newbie by
> not indenting your code properly, which is impossible in Python.
>
> Python is much, much cleaner. I don't know how anyone can honestly say
> Ruby is cleaner than Python.

I will. I developed on both (Python was first) and I think that ruby I
very clean and maybe cleaner than Python. Also I don't know any
situation where you need to pronounce your code symbol by symbol. You
might need to pronounce some semantics.

And you're wrong with blocks.

About indent your right. It helps newbies indent code becouse they
must to. But most of professional developers started with Pascal and
then C and they all indent well :) it is about culture and it is what
about teacher should say.

==============================================================================
TOPIC: pyfltk ducumentation question
http://groups.google.com/group/comp.lang.python/t/cf2d48d83ff97e29?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 1:45 am
From: tinnews@isbd.co.uk

I have just installed pyfltk version 1.1.4 on my xubuntu 9.10 system,
it's working OK and a fairly trivial little program I have written is
able to pop up a GUI window.

However I'm now a bit stuck as the documentation seems a little
sparse. For example I'm using FL_Multiline_Output and can't find
enough detail to enable me to use its methods.

I start from:-

http://pyfltk.sourceforge.net/docs/CH3_Common.html

This tells me that there is a FL_Multiline_Output widget and that it
has a value() method, this is what I have used to display some text in
my little application.

When I click on the FL_Multiline_Output link in the above page it
takes me to:-

http://pyfltk.sourceforge.net/docs/fltk.html#Fl_Multiline_Output

which lists all the methods and other bits and pieces belonging to
Fl_Multiline_Output but as far as I can see that's it, there is no
further information. The methods are links but they only link to
themselves, when you click on them the browser moves the method to the
top of the display window.

Am I missing something obvious or do I need the FLTK documentation to
give me the detail I need?

--
Chris Green

==============================================================================
TOPIC: test -- please ignore
http://groups.google.com/group/comp.lang.python/t/87ebbae4005795a5?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 2:01 am
From: kj

(my replies in a different comp.lang.python thread are getting
rejected by the server; i have no problem posting to alt.test; and
i'm trying to toubleshoot the problem further.)

== 2 of 2 ==
Date: Wed, Feb 3 2010 3:05 am
From: Ben Finney

kj <no.email@please.post> writes:

> (my replies in a different comp.lang.python thread are getting
> rejected by the server; i have no problem posting to alt.test; and
> i'm trying to toubleshoot the problem further.)

Thank you for this explanation. It is important to know that you've
tried the less obtrusive diagnostics first. Good hunting.

--
\ "To have the choice between proprietary software packages, is |
`\ being able to choose your master. Freedom means not having a |
_o__) master." —Richard M. Stallman, 2007-05-16 |
Ben Finney

==============================================================================
TOPIC: PEP 3147 - new .pyc format
http://groups.google.com/group/comp.lang.python/t/7a0d8230a5907885?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 2:55 am
From: Daniel Fetchinson

>>> I like seeing them in the same place as the source file, because when I
>>> start developing a module, I often end up renaming it multiple times
>>> before it settles on a final name. When I rename or move it, I delete
>>> the .pyc file, and that ensures that if I miss changing an import, and
>>> try to import the old name, it will fail.
>>>
>>> By hiding the .pyc file elsewhere, it is easy to miss deleting one, and
>>> then the import won't fail, it will succeed, but use the old, obsolete
>>> byte code.
>>
>>
>> Okay, I see your point but I think your argument about importing shows
>> that python is doing something suboptimal because I have to worry about
>> .pyc files. Ideally, I only would need to worry about python source
>> files.
>
> That's no different from any language that is compiled: you have to worry
> about keeping the compiled code (byte code or machine language) in sync
> with the source code.

True.

> Python does most of that for you: it automatically recompiles the source
> whenever the source code's last modified date stamp is newer than that of
> the byte code. So to a first approximation you can forget all about
> the .pyc files and just care about the source.

True, but the .pyc file is lying around and I always have to do 'ls
-al | grep -v pyc' in my python source directory.

> But that's only a first approximation. You might care about the .pyc
> files if:
>
> (1) you want to distribute your application in a non-human readable
> format;

Sure, I do care about pyc files, of course, I just would prefer to
have them at a separate location.

> (2) if you care about clutter in your file system;

You mean having an extra directory structure for the pyc files? This I
think would be better than having the pyc files in the source
directory, but we are getting into 'gut feelings' territory :)

> (3) if you suspect a bug in the compiler;

If the pyc files are somewhere else you can still inspect them if you want.

> (4) if you are working with byte-code hacks;

Again, just because they are somewhere else doesn't mean you can't get to them.

> (5) if the clock on your PC is wonky;

Same as above.

> (6) if you leave random .pyc files floating around earlier in the
> PYTHONPATH than your source files;
>
> etc.
>
>
>
>
>> There is now a chance to 'fix' (quotation marks because maybe
>> there is nothing to fix, according to some) this issue and make all pyc
>> files go away and having python magically doing the right thing.
>
> Famous last words...
>
> The only ways I can see to have Python magically do the right thing in
> all cases would be:
>
> (1) Forget about byte-code compiling, and just treat Python as a purely
> interpreted language. If you think Python is slow now...

I'm not advocating this option, naturally.

> (2) Compile as we do now, but only keep the byte code in memory. This
> would avoid all worries about scattered .pyc files, but would slow Python
> down significantly *and* reduce functionality (e.g. losing the ability to
> distribute non-source files).

I'm not advocating this option either.

> Neither of these are seriously an option.

Agreed.

>> A
>> central pyc repository would be something I was thinking about, but I
>> admit it's a half baked or not even that, probably quarter baked idea.
>
> A central .pyc repository doesn't eliminate the issues developers may
> have with byte code files, it just puts them somewhere else, out of
> sight, where they are more likely to bite.

Here is an example: shared object files. If your code needs them, you
can use them easily, you can access them easily if you want to, but
they are not in the directory where you keep your C files. They are
somewhere in /usr/lib for example, where they are conveniently
collected, you can inspect them, look at them, distribute them, do
basically whatever you want, but they are out of the way, and 99% of
the time while you develop your code, you don't need them. In the 1%
of the case you can easily get at them in the centralized location,
/usr/lib in our example.

Of course the relationship between C source files and shared objects
is not parallel to the relationship to python source files and the
created pyc files, please don't nitpick on this point. The analogy is
in the sense that your project inevitable needs for whatever reason
some binary files which are rarely needed at hand, only the
linker/compiler/interpreter/etc needs to know where they are. These
files can be stored separately, but at a location where one can
inspect them if needed (which rarely happens).

Cheers,
Daniel

--
Psss, psss, put it down! - http://www.cafepress.com/putitdown

==============================================================================
TOPIC: Dreaming of new generation IDE
http://groups.google.com/group/comp.lang.python/t/e019614ea149e7bd?hl=en
==============================================================================

== 1 of 5 ==
Date: Wed, Feb 3 2010 3:10 am
From: Vladimir Ignatov

Hello,

I am sitting here for quite some time, but usually keep silent ;-) I
use Python since 2003 both "professionally" and for my hobby projects
and love it a much.
I notice however, that "maintaining" existing/older python code is may
be not so enjoyable task. It may be even harder than supporting old
code written in some type of "static" languages (like Java or C++).
Surely "dynamic" nature of python comes with price.

Finally I develop a feeling that strong instrumentation / tools can
bring us the best of two worlds. That I am dreaming on is an absolute
new type/class of IDE suitable for Python and potentially for other
dynamic-type languages. Instead of current text-oriented IDEs, it
should be a database-centric and resemble current CAD systems instead
of being just "fancy text editor". Source text should be an output
product of that CAD and not a "source material" itself.

Well. I understand that it is a very ambitious and experimental stuff.
Great efforts and motivation needed even to get something "runnable".
So I am looking for someone to get in kind of "virtual partnership".
If someone interesting it that soft of stuff, I would like to talk and
discuss this system.

Vladimir Ignatov

== 2 of 5 ==
Date: Wed, Feb 3 2010 5:07 am
From: Paul Rubin

Vladimir Ignatov <kmisoft@gmail.com> writes:
> I notice however, that "maintaining" existing/older python code is may
> be not so enjoyable task. It may be even harder than supporting old
> code written in some type of "static" languages (like Java or C++).
> Surely "dynamic" nature of python comes with price.

Yes, this is a well known drawback of dynamic typing. The usual remedy
is lots and lots of test automation (a full suite of unit and
integration tests that you run on every build, that check the properties
of basically every function in your program).

> Instead of current text-oriented IDEs, it
> should be a database-centric and resemble current CAD systems

I've never used a current CAD system, so I can't make any sense of this.
I don't see how databases would help.

== 3 of 5 ==
Date: Wed, Feb 3 2010 5:16 am
From: Stefan Behnel

Paul Rubin, 03.02.2010 14:07:
>> Instead of current text-oriented IDEs, it
>> should be a database-centric and resemble current CAD systems
>
> I've never used a current CAD system, so I can't make any sense of this.
> I don't see how databases would help.

Just like they help in current IDEs to index the source code.

Stefan

== 4 of 5 ==
Date: Wed, Feb 3 2010 5:18 am
From: Adam Tauno Williams

On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote:
> Hello,
> I am sitting here for quite some time, but usually keep silent ;-) I
> use Python since 2003 both "professionally" and for my hobby projects
> and love it a much.
> I notice however, that "maintaining" existing/older python code is may
> be not so enjoyable task. It may be even harder than supporting old
> code written in some type of "static" languages (like Java or C++).
> Surely "dynamic" nature of python comes with price.

Yes, it certainly does. Not that you'll get many Pythonistas to confess
to that fact. Somehow those who brag about the readability and
expressiveness of source code just cannot admit that:

class.method(sting name, int count)

- is *obviously* more expressive than -

class.method(name, count)

Oh, well.

This is obvious even in the Python documentation itself where one
frequently asks oneself "Uhh... so what is parameter X supposed to be...
a string... a list... ?"

Not knocking Python; Python is great. I maintain a rapidly growing
Python code base. But the above is almost comically funny sometimes
[sand.insert_head(pythonista)].

> Finally I develop a feeling that strong instrumentation / tools can
> bring us the best of two worlds. That I am dreaming on is an absolute
> new type/class of IDE suitable for Python and potentially for other
> dynamic-type languages. Instead of current text-oriented IDEs, it
> should be a database-centric and resemble current CAD systems instead
> of being just "fancy text editor". Source text should be an output
> product of that CAD and not a "source material" itself.

Ugh, please NO! This has been attempted many many times in many
environments - it always fails *terribly*.

> Well. I understand that it is a very ambitious and experimental stuff.
> Great efforts and motivation needed even to get something "runnable".
> So I am looking for someone to get in kind of "virtual partnership".
> If someone interesting it that soft of stuff, I would like to talk and
> discuss this system.

== 5 of 5 ==
Date: Wed, Feb 3 2010 5:35 am
From: Stefan Behnel

Adam Tauno Williams, 03.02.2010 14:18:
> This is obvious even in the Python documentation itself where one
> frequently asks oneself "Uhh... so what is parameter X supposed to be...
> a string... a list... ?"
>
> Not knocking Python; Python is great. I maintain a rapidly growing
> Python code base. But the above is almost comically funny sometimes
> [sand.insert_head(pythonista)].

So, what's "pythonista" in the above? A dummy?

Stefan

==============================================================================
TOPIC: Meet Arab, Russian, American Singles From All Over The World
http://groups.google.com/group/comp.lang.python/t/5363ad4b14027d22?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 5:47 am
From: qwertyyyy

Meet Singles In Your Area
Arabs, American, Russian Singles
From All Over The World
Waiting For You At Marinzo
Join Marinzo And Start Your Love Life Now
Join Marinzo Now For Free !!

Enjoy exciting features offered by our site:
* Profiles with galleries and audio/video
* Personal weblogs and friends-lists
* Audio/video chat, IM and recorder
* SPAM-blocking and anti-SPAM system
* ZIP-codes search, matchmaking and so much
more!!

http://www.marinzo.com

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

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

Wednesday, February 3, 2010

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

No comments:

Post a Comment