Re: Frameworks for "Non-Content Oriented Web Apps"

[paolo_veronelli]

[EMAIL PROTECTED] wrote:
Hi,
There are great Python Web Application Framework. But most of them are
meant for content oriented web apps.
Is there something that can ease the development of application that
are not content oriented(I call them "NON CONTENT-ORIENTED WEB
APPLICATIONS" because I don't know what else to call them). I mean the
applications like, accounting,  high volume data entry apps,  where
normally GUI clients have ruled. I know very high quality ERP and
similar packages have been implemented in a web based environment. But
problem is that they have been developed with the tools that were
actually meant for content oriented apps like Zope, PHP, etc.
But is there some sort of framework or something that is actually meant
for such web apps,application that make heavy use of forms, have very
high amount of user interaction etc.
What I am asking here may sound off beat, but I think, in todays world
where web based solutions offers such a flexibility, we really need it.
I also know that I am to ambiguous, but as is the characteristic of
this wonderful community, talks that start as most abigous, transform
in crystal clear.
PS: I am a web developer, using PHP for living. I have been playing
with python for a while. I found python is really a cool language(do I
need to say that ;-)) with a really, really impressive collection of
modules and frameworks. While developing a school information system, I
felt the need of such a framework that makes developing of "Non-Content
Oriented Web-Apps" easy.
I know I posted a similar message earlier, but this time I a bit more
general.
 

In pytypus everything is not content is metadata( a part from some of 
the code ,which part is useful for accessing informations) ,so my 
definition will simply be metadata oriented.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Integrating Python into a C++ app

[Alex Martelli]

Ben Sizer <[EMAIL PROTECTED]> wrote:

> I know the conventional wisdom is to write the whole app in Python and
> only extend with C++ where speed is an issue, but I already have a
> large C++ app that I'd like to add Python to. Ideally I'd rewrite the
> whole app in Python but I don't have time to do that and maintain the
> old system at the same time. So my next thought was to perhaps
> integrate the two and slowly migrate modules and classes across from
> C++ to Python. If it matters, the main reason I'm interested in doing
> this is because I appreciate the productivity of Python and would like
> to take advantage of that as I add features to the current code, to
> reduce bugs and cut development time.

This seems quite a reasonable approach to me.


> I've read a few good things in this group about Elmer
> (http://elmer.sourceforge.net), but I'm not sure how simply that
> accommodates calls in the reverse direction (from Python code back into
> C++). Are there any other options that would require a minimum of
> rewriting of code? Does anybody have any experience of such a project?

Sorry, haven't tried elmer yet.  When I did such embedding a few years
ago I used Boost Python (www.boost.org) -- Boost has kept growing better
with the years so today it should be even easier.  OTOH, the C++
application was already well structured according to Lakos' ideas
(expressed in his book about large-scale program design in C++):
components communicating across interfaces, rather than a free-for-all
of jumbles of dependencies.  The interfaces being abstract C++ classes,
and the building of concrete instances always going through Factory
design patterns, Boost's abilities to wrap C++ classes as Python types
and let Python classes inherit from such wrapped C++ classes so that
normal virtual-method-call C++ approaches proved sufficient.

(In the end, after several experiments, we ended up using COM, since the
application only ran on Windows anyway; much of the COM was of course
done in Python, but that's another issue).

I suspect that few legacy C++ applications are well structured in terms
of components and interfaces.  But then, trying to do any kind of major
surgery without serious rearchitecting tends to produce inferior results
anyway.  And the rearchitecting is quite advisable whether you do end up
using any Python, or not -- you want good, clean components, cohesive
and coherent, with a good graph of dependencies, unit-tests for each
component, dependency inversion (a la Robert Martin) to avoid
dependencies going the wrong way, etc, etc.  Lakos and Martin are the
two authors I would suggest reading.  Lakos' book is old, and among his
major concerns is using just the subset of C++ you could rely on, years
ago; you can probably ignore those issues safely today (to use Boost,
you need a good recent C++ compiler with impeccable template support,
anyway, for example).


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: input record sepArator (equivalent of "$|" of perl)

[Alex Martelli]

Mike Meyer <[EMAIL PROTECTED]> wrote:
   ...
> Trivia question: Name the second most powerfull country on earth not
> using the metric system for everything.

Well, then, just name the 2nd most powerful country on earth, period
(I'm not going to get myself in trouble by guessing whether said 2nd
country is China, Russia, "Europe" [not a country, I know;-)], ...).

TVs and other displays are sold as "20 inches" (or whatever) everywhere,
printers' resolutions are always given in pixels per inch, etc.


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks for "Non-Content Oriented Web Apps"

[michele . simionato]

Well, with your first post you managed to get a very unclear picture of
what you mean by "non-content oriented Web Application" ;-)

Judging from your following posts, you want an easy way to construct
Web interfaces, i.e. forms. This can be done with any Web framework,
but a typical Web framework provides a lots of content-related
functionality
you don't want. For instance you could use Plone for your task, but you
would waste 99% of its functionality and it would be absolutely
overkill.

If I had to write a Web application such as Webmin, for instance, i.e.
one that use a Web interface to manage other applications, I would
use Quixote as my Web framework of choice. Its key points are
simplicity and the fact that it provides *very little*. Just the form
library would be enough for you. Since the different part of Quixote
are well separated, the learning curve is really really small.

It also takes a little time to evaluate it. I suggest you to give a
look
at it.


Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using ICL to compile C extensions

["Martin v. Löwis"]

[EMAIL PROTECTED] wrote:
Does anyone know how I can use "icl" (Intel C++) to compile C
extensions? I'm on Windows, and my Python is compiled using VS7.1
(binary distribution). Right now, when I run setup.py install, it uses
cl.exe (MSVC++ Toolkit 2003), and I would like to use icl because
MSVC++ 2003 does not support C99.
It should be possible to use this compiler, as long as you can link to
msvcr71.dll (i.e. as long as you have header files of the MS C library,
and an import library that links to msvcr71).
Whether you can use distutils to run the build process is a different
issue - you might need to extend distutils.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[Eric Pederson]

Alex Martelli commented:


> It's not just _foreign_ companies -- regional clustering of all kinds 
> of
> business activities is a much more widespread phenomenon.  Although I'm
> not sure he was the first to research the subject, Tjalling Koopmans, 
> as
> part of his lifework on normative economics for which he won the Nobel
> Prize 30 years ago, published a crucial essay on the subject about 50
> years ago (sorry, can't recall the exact date!) focusing on
> _indivisibilities_, leading for example to transportation costs, and to
> increasing returns with increasing scale.  Today, Paul Krugman is
> probably the best-known name in this specific field (he's also a
> well-known popularizer and polemist, but his specifically-scientific
> work in economics has mostly remained in this field).
> 
> > China right now)? According to standard economics it should
> > not happen - what's the point of getting into this overpriced
> > city if elsewhere in this country you can find just as good
> > conditions for business. 
> 
> Because you can't.  "Standard" economics, in the sense of what you 
> might
> have studied in college 25 years ago if that was your major, is quite
> able to account for that if you treat spatial variables as exogenous to
> the model; Krugman's breakthroughs (and most following work, from what 
> I
> can tell -- but economics is just a hobby for me, so I hardly have time
> to keep up with the literature, sigh!) have to do with making them
> endogenous.
> 
> Exogenous is fine if you're looking at the decision a single firm, the
> N+1 - th to set up shop in (say) a city, faces, given decisions already
> taken by other N firms in the same sector.
> 
> The firm's production processes have inputs and outputs, coming from
> other firms and (generally, with the exception of the last "layer" of
> retailers etc) going to other firms.  Say that the main potential 
> buyers
> for your firm's products are firms X, Y and Z, whose locations all
> "happen to be" (that's the "exogenous" part) in the Q quarter of town.
> So, all your competitors have their locations in or near Q, too.  Where
> are you going to set up your location?   Rents are higher in Q than
> somewhere out in the boondocks -- but being in Q has obvious 
> advantages:
> your salespeople will be very well-placed to shuttle between X, Y, Z 
> and
> your offices, often with your designers along so they can impress the
> buyers or get their specs for competitive bidding, etc, etc.  At some
> points, the competition for rents in quarter Q will start driving some
> experimenters elsewhere, but they may not necessarily thrive in those
> other locations.  If, whatever industry you're in, you can strongly
> benefit from working closely with customers, then quarter Q will be
> where many firms making the same products end up (supply-side
> clustering).
> 
> Now consider a new company Z set up to compete with X, Y and Z.  Where
> will THEY set up shop?  Quarter Q has the strong advantage of offering
> many experienced suppliers nearby -- and in many industries there are
> benefits in working closely with suppliers, too (even just to easily
> have them compete hard for your business...).  So, there are easily
> appreciated exogenous models to explain demand-side clustering, too.
> 
> That's how you end up with a Holliwood, a Silicon Valley, a Milan (for
> high-quality fashion and industrial design), even, say, on a lesser
> scale, a Valenza Po or an Arezzo for jewelry.  Ancient European cities
> offer a zillion examples, with streets and quarters named after the
> trades or professions that were most clustered there -- of course, 
> there
> are many other auxiliary factors related to the fact that people often
> _like_ to associate with others of the same trade (according to Adam
> Smith, generally to plot some damage to the general public;-), but
> supply-side and demand-side, at least for a simpler exogenous model, 
> are
> plenty.
> 
> Say that it's the 18th century (after the corporations' power to stop
> "foreign" competition from nearby towns had basically waned), you're a
> hat-maker from Firenze, and for whatever reason you need to move
> yourself and your business to Bologna.  If all the best hat-makers'
> workshops and shops are clustered around Piazza dell'Orologio, where 
> are
> YOU going to set up shop?  Rents in that piazza are high, BUT - that's
> where people who want to buy new hats will come strolling to look at 
> the
> displays, compare prices, and generally shop.  That's close to where
> felt-makers are, since they sell to other hat-makers.  Should your
> business soon flourish, so you'll need to hire a worker, that's where
> you can soon meet all the local workers, relaxing with a glass of wine
> at the local osteria after work, and start getting acquainted with
> everybody, etc, etc...


Right, and distribution in general is "clumpy"; i.e. one doesn't find the 
spatial distribution of people to be uniform (unless at saturation!)

Re: Frameworks for "Non-Content Oriented Web Apps"

[Alex Martelli]

<[EMAIL PROTECTED]> wrote:

> Moreover, I recently saw Dabo(http://www.dabodev.com/about), a
> framework for developing 3 tier apps with Python and wxPython(and other
> supported GUI toolkits). I have not tried it but I think something
> similar, but for web-apps, is a close definition of "A Framework for
> Non-Content Oriented Web Apps".

Once you're on a multilayer track, whether the presentation is on the
web or on some other UI should just be an issue for the very last layer
(closest to the user).  That's definitely how we did things at AB Strakt
(www.strakt.com).  Of course, the web-based presentation layer will be
generally simpler/poorer than ones based on richer GUI toolkits -- as a
compensation, it may more easily be "skinnable" by using CSS and the
like, and it's way more easily _testable_ thanks to many good packages
for webpage-generators testing.


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[flamesrock]

Well, I'm not a seasoned programmer like you but I have to say Python
is the singlebest language I've worked with to date. In a matter of
weeks I learned to do things that took me months in other languages and
even found the process enjoyable.

Maybe you are right. If so, couldn't Python be forked into something
like you describe, while still remaining compatible at the core? (if
anyones willing)

Python++ anyone?

-- 
http://mail.python.org/mailman/listinfo/python-list

search backward

[Robert]

I need to find the location of a short string in a long string. The
problem however is that i need to search backward.

Does anybody know how to search in reverse direction?


Thanks,
Robert
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Paul Rubin]

"flamesrock" <[EMAIL PROTECTED]> writes:
> Maybe you are right. If so, couldn't Python be forked into something
> like you describe, while still remaining compatible at the core? (if
> anyones willing)

It's not an issue with the Python core (language); I read that post as
mostly bemoaning the poor state of the runtime library.  I feel the
same concerns, however, fixing it is a lot of work.
-- 
http://mail.python.org/mailman/listinfo/python-list

Deferred expressions (was Re: Lambda as declarative idiom)

[Nick Coghlan]

Steven Bethard wrote:
Nick Coghlan: def-from syntax [4]
(def f(a) + o(b) - o(c) from (a, b, c))
(def x * x from (x))
(def x from ())
(def x.bar(*a, **k) from (*a, **k))
((def x(*a, **k) from ()) for x, a, k in funcs_and_args_list)
After a bit more musing, this is definitely my preferred syntax. I'd call it a 
'deferred expression' rather than an anonymous function, though. The name change 
may seem minor, but it changes the emphasis of the feature from how it's 
implemented to what it is useful for (i.e. deferring evaluation of an expression 
until call time).

It's also conducive to a clean no-argument syntax - simply make the 'from' claus 
optional when the argument list is empty.

'def' and 'from' are already keywords, so there shouldn't be any compatibility 
problems.

Michael Spencer's idea of using 'for' instead of 'from' was quite interesting, 
but the use of 'for' without a corresponding 'in' feels a bit misleading :)

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: search backward

[Aaron Bingham]

Robert wrote:
I need to find the location of a short string in a long string. The
problem however is that i need to search backward.
Does anybody know how to search in reverse direction?
>>> "foofoo".find("foo")
0
>>> "foofoo".rfind("foo")
3
>>> "foofoo".index("foo")
0
>>> "foofoo".rindex("foo")
3
--

Aaron Bingham
Application Developer
Cenix BioScience GmbH

--
http://mail.python.org/mailman/listinfo/python-list

python 3000 and removal of builtin callable

[Mirko Zeibig]

Hello everybody,
I recently stumbled across the proposal of removing `callable` in Python 
3000 (http://python.org/peps/pep-3000.html) catching an exception 
instead, maybe something like this:
--- snip ---
[EMAIL PROTECTED] mize]$ python2.3
Python 2.3.3 (#1, Apr  6 2004, 01:47:39)
[GCC 3.3.3 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> i = 5
>>> i()
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: 'int' object is not callable
>>>
--- snap ---

This is not an option for e.g. IDEs as some functions might actually do 
something when called ;-) and I like `callable` for introspection.

Other ways would be to check for the `__call__` attribute or use several 
methods of the `inspect`-Module, both of which are not better than 
`callable` IMHO.

Regards
Mirko
--
Insert a sig please.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[michele . simionato]

Maybe a PSF grant would help? I guess this has been considered ...
Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Hlelp clean up clumpsy code

[Steven Bethard]

It's me wrote:
Another newbie question.
There must be a cleaner way to do this in Python:
 section of C looking Python code 
a = [[1,5,2], 8, 4]
a_list = {}
i = 0
for x in a:
if isinstance(x, (int, long)):
x = [x,]
for w in [y for y in x]:
i = i + 1
a_list[w] = i
print a_list
#
The code prints what I want but it looks so "C-like".  How can I make it
more Python like?
Don't know what version of Python you're using, but if you're using 2.4 
(or with a few slight modifications, with 2.3), you can write:

py> dict((item, i+1)
...  for i, item in enumerate(
...  a_sub_item
...  for a_item in a
...  for a_sub_item
...  in isinstance(a_item, (int, long)) and [a_item] or a_item))
{8: 4, 1: 1, 2: 3, 4: 5, 5: 2}
Basically, I use a generator expression to flatten your list, and then 
use enumerate to count the indices instead of keeping the i variable.

Steve
--
http://mail.python.org/mailman/listinfo/python-list

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30)

[holger krekel]

On Fri, Dec 31, 2004 at 19:18 +0100, Alex Martelli wrote:
> Cameron Laird <[EMAIL PROTECTED]> wrote:
>...
> >  Yippee!  The martellibot promises to explain Unicode for Pythoneers.
> >  http://groups-beta.google.com/group/comp.lang.python/msg/6015a5a05c206712
> 
> Uh -- _did_ I?  Eeep... I guess I did... mostly, I was pointing to
> Holger Krekel's very nice recipe (not sure he posted it to the site as
> well as submitting it for the printed edition, but, lobby _HIM_ about
> that;-).

FWIW, i added the recipe back to the online cookbook.  It's not perfectly
formatted but still useful, i hope. 

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/361742 

cheers, 

holger

P.S: happy new year. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: search backward

[Steven Bethard]

Robert wrote:
I need to find the location of a short string in a long string. The
problem however is that i need to search backward.
Does anybody know how to search in reverse direction?
How about str.rfind?
py> s = 'abc:def:abc'
py> s.rfind('abc')
8
Steve
--
http://mail.python.org/mailman/listinfo/python-list

csh to Python

[Nader Emami]

Hello,
I am new in Python world, and would like to begin with
translate a csh file to a python script. Could somebody give
me an advise (documentation or web-site) where I can do that.
with regards,
Nader
--
http://mail.python.org/mailman/listinfo/python-list

Re: Hlelp clean up clumpsy code

[Nick Coghlan]

It's me wrote:
Another newbie question.
There must be a cleaner way to do this in Python:
 section of C looking Python code 
a = [[1,5,2], 8, 4]
a_list = {}
i = 0
for x in a:
if isinstance(x, (int, long)):
x = [x,]
for w in [y for y in x]:
i = i + 1
a_list[w] = i
print a_list
#
The code prints what I want but it looks so "C-like".  How can I make it
more Python like?
Firstly, calling your dictionary "a_list" is evil. . .
Secondly, explaining what you want the code to do in English is handy when 
asking for help cleaning up code (since we then know which features are 
deliberate, and which are accidental implementation artificacts).

If I'm reading the code correctly, you want to flatten a data structure which 
may contain either substructures or actual elements.

A custom generator will do nicely:
Py> def flatten(seq):
...   for x in seq:
... if hasattr(x, "__iter__"):
...   for y in flatten(x):
... yield y
... else:
...   yield x
...
Py> data = [[1,5,2],8,4]
Py> val_to_pos = {}
Py> for i, x in enumerate(flatten(data)):
...   val_to_pos[x] = i + 1
...
Py> print val_to_pos
{8: 4, 1: 1, 2: 3, 4: 5, 5: 2}
Not any shorter, but this version works correctly for any leaf elements which 
don't supply __iter__ (e.g. strings), and internal elements which do (e.g. 
tuples) and the depth is limited only by the maximum level of recursion. Don't 
try to flatten a circular structure, though :)

You may not even need to write the generator, since if you have Tkinter, that 
already supplies a near-equivalent function:

Py> from Tkinter import _flatten as flatten
Py> data = [[1,5,2],8,4]
Py> val_to_pos = {}
Py> for i, x in enumerate(flatten(data)):
...   val_to_pos[x] = i + 1
...
Py> print val_to_pos
{8: 4, 1: 1, 2: 3, 4: 5, 5: 2}
It even works with strings as leaf elements:
Py> data = [["abc","def",2],8,"xyz"]
Py> flatten(data)
('abc', 'def', 2, 8, 'xyz')
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Alex Martelli]

Iwan van der Kleyn <[EMAIL PROTECTED]> wrote:

> to be determine the way foreward for Python: more features, increased
> complexity, less dynamism. Lots of syntax crud, without addressing the

As a student of human nature, I'm _really_ curious as to how one could
possibly read the key document:
http://www.python.org/peps/pep-3000.html
and think in consequence of "more features, increased complexity".

Also, you keep talking about "the core python team" on the basis, it
would appear, of reading one document by Guido.  Have you bothered doing
a MINIMUM of homework, such as, looking at
http://www.amk.ca/diary/archives/cat_python.html
and specifically AMK's entry for September 30?  I'm trying to understand
whether you completely missed doing the most elementary amount of
background searching before venting on the group, or if you did find and
read the obvious documents and somehow STILL manage to completely ignore
their contents or read them as saying exactly the opposite of what they
_do_ say...


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

why does UserDict.DictMixin use keys instead of __iter__?

[Steven Bethard]

Sorry if this is a repost -- it didn't appear for me the first time.
So I was looking at the Language Reference's discussion about emulating
container types[1], and nowhere in it does it mention that .keys() is
part of the container protocol.  Because of this, I would assume that to
use UserDict.DictMixin correctly, a class would only need to define
__getitem__, __setitem__, __delitem__ and __iter__.  So why does
UserDict.DictMixin require keys() to be defined?
py> class D(object, UserDict.DictMixin):
... """Simple dict wrapper that implements container protocol"""
... def __init__(self, dict): self.dict = dict
... def __len__(self, key): return len(self.dict)
... def __getitem__(self, key): return self.dict[key]
... def __setitem__(self, key, value): self.dict[key] = value
... def __delitem__(self, key): del self.dict[key]
... def __iter__(self): return iter(self.dict)
... def __contains__(self, key): return key in self.dict
...
py> d = D(dict(a=1, b=2))
py> d.clear()
Traceback (most recent call last):
  File "", line 1, in ?
  File "C:\Program Files\Python\lib\UserDict.py", line 114, in clear
for key in self.keys():
AttributeError: 'D' object has no attribute 'keys'
py> d.keys()
Traceback (most recent call last):
  File "", line 1, in ?
AttributeError: 'D' object has no attribute 'keys'
I thought about submitting a patch, but I couldn't think of a way that
didn't raise backwards compatibility concerns...
Steve
[1]http://docs.python.org/ref/sequence-types.html
--
http://mail.python.org/mailman/listinfo/python-list

Re: How can engineers not understand source-code control?

[Mark Carter]

> Cameron Laird wrote:
>
>> I've seen the infatuation for Excel (and so on) for years,
True story: when I began working for my current employer, there was a 
guy there doing some work with a spreadsheet. He was given two weeks to 
perform the task. It was a loss-leader to get some real work from the 
client.

There already existed a spreadsheet, which did financial projections. It 
used VBA fairly extensively, and his task was to adapt it to remove the 
VBA code. This means converting things like functions into equivalent 
cell formulae. The rationale behind this is that VBA is too hard for 
most people to understand, whereas formulae are easier to understand. 
Conditionals look really confusing in formulae, and I don't know how he 
coped with loops. And then, of course, you have to replicate them to 
every cell that requires them. Can you imagine that? Is this very the 
definition of madness, or what?

The whole thing was a gigantic spreadsheet (I can't remember, it was 
either 9Mb or 90Mb in size), and kept crashing every few minutes. Utter 
utter insanity. Whenever he went back the client, she demanded 
improvements. We had effectively told her that she could have whatever 
whe wanted. And oh, it would only take 2 weeks. The managers never 
pulled the plug on the project.

Apparently, our guy sat in on a conversation that the client had with a 
potential contractor who would replace the spreadsheet. His first 
question was, surprise surprise, "why on earth did you try to do it that 
way?"

The thing is, our guy was scheduled to be booted out the door because he 
was in a business area that was being discontinued by us, so from my 
employer's point-of-view, I guess that all this lunacy actually made sense.
--
http://mail.python.org/mailman/listinfo/python-list

Re: why does UserDict.DictMixin use keys instead of __iter__?

[Nick Coghlan]

Steven Bethard wrote:
Sorry if this is a repost -- it didn't appear for me the first time.
So I was looking at the Language Reference's discussion about emulating
container types[1], and nowhere in it does it mention that .keys() is
part of the container protocol.  Because of this, I would assume that to
use UserDict.DictMixin correctly, a class would only need to define
__getitem__, __setitem__, __delitem__ and __iter__.  So why does
UserDict.DictMixin require keys() to be defined?
Because it's a DictMixin, not a ContainerMixin?
.keys() is definitely part of the standard dictionary interface, and not 
something the mixin can derive from the generic container methods.

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list

Re: How do I make Windows Application with Python ?

[Ola Natvig]

BOOGIEMAN wrote:
On Mon, 03 Jan 2005 17:19:22 -0500, Peter Hansen wrote:

What do you mean by "Windows Applications"?  I'm running
Python on Windows XP, so every program I write with
Python is a "Windows application" by my definition.  Obviously
you are using a different one.
(And if you just mean "it has a GUI", then my answer is
"I use wxPython with Python".  There is also Tkinter, and
other options.  Please ask a more specific, detailed question
to get useful answers.)

Well, I programmed a little in MS Visual Studio 2003, and there you have
Console apllication and Windows application (among others). Windows one is
with buttons and other gadgets. So, I want to make applications that
doesn't open console to display result, I want to display it into the
message box. Also, I want to use that application on the computers where
Python isn't installed
if you are familliar with the .NET framework you can use the beta 
release og Python.NET to create your GUI. It gives you access to the 
Windows Forms controlls in the .NET framework

--
--
 Ola Natvig <[EMAIL PROTECTED]>
 infoSense AS / development
--
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[michele . simionato]

But then I have THREE published recipes!!
Does that mean that I get three free copies of the cookbook ? ;-)
Michele

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: why does UserDict.DictMixin use keys instead of __iter__?

[John Machin]

Steven Bethard wrote:
> Sorry if this is a repost -- it didn't appear for me the first time.
>
>
> So I was looking at the Language Reference's discussion about
emulating
> container types[1], and nowhere in it does it mention that .keys() is
> part of the container protocol.

I don't see any reference to a "container protocol". What I do see is
(1) """It is also recommended that mappings provide the methods keys(),
..."""
(2) """The UserDict module provides a DictMixin class to help create
those methods from a base set of __getitem__(), __setitem__(),
__delitem__(), and keys(). """

> Because of this, I would assume that to
> use UserDict.DictMixin correctly, a class would only need to define
> __getitem__, __setitem__, __delitem__ and __iter__.

So I can't see why would you assume that, given that the docs say in
effect "you supply get/set/del + keys as the building blocks, the
DictMixin class will provide the remainder". This message is reinforced
in the docs for UserDict itself.

> So why does
> UserDict.DictMixin require keys() to be defined?

Because it was a reasonable, documented, design?

In any case, isn't UserDict past history? Why are you mucking about
with it?

-- 
http://mail.python.org/mailman/listinfo/python-list

Problem with Python module

[Maneesh]

Hi,
   I want to connect to a remote MS SQL Server 2000 database through
my Fedora Core 2 machine via Python scripts. I have successfully
installed freetds & unixODBC and can now connect to the desired DB
through tsql(freetds) & isql(unixODBC). I installed mxODBC (RPM &
source) to be able to connect to the DB via Python scripts without any
success.

The code(db3.py) under test is as follows:
--
#!/usr/bin/python2.3

import mx.ODBC.unixODBC

dsn="ps0196"

conn=mx.ODBC.unixODBC.Connect (dsn, "maneesh_singh", "newuser")

print "Content-Type: text/plain"
print 

cursorhandle=conn.cursor()

print "MySQL Databse via mxODBC\n"
cursorhandle.execute("select * from tb_mis_team")

for i in cursorhandle.fetchall():
print i

print cursorhandle.fetchall()

for i in cursorhandle.fetchall():
print i
--

The output is as follows:
--
[EMAIL PROTECTED] cgi-bin]# python db3.py
Traceback (most recent call last):
  File "db3.py", line 4, in ?
import mx.ODBC.unixODBC
  File "/usr/lib/python2.3/site-packages/mx/ODBC/unixODBC/__init__.py",
line 8, in ?
from mxODBC import *
ImportError: libiodbcinst.so.2: cannot open shared object file: No
such file or directory
--

Additional info:
--
[EMAIL PROTECTED] unixODBC]# pwd
/usr/lib/python2.3/site-packages/mx/ODBC/unixODBC
[EMAIL PROTECTED] unixODBC]# ldd ./mxODBC.so
linux-gate.so.1 =>  (0x0070b000)
libodbc.so.1 => /usr/lib/libodbc.so.1 (0x00b26000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x007ca000)
libc.so.6 => /lib/tls/libc.so.6 (0x00eaa000)
libiodbcinst.so.2 => not found
libdl.so.2 => /lib/libdl.so.2 (0x006b2000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0089d000)
---

I want to use unixODBC and not iODBC, why is mxODBC looking for
iODBC's libraray? I had earlier tried to install iODBC,
unsuccessfully, hence shifted over to unixODBC. The missing iODBC
library exist in /usr/local/lib folder. Do I need to link the iODBC
library to mxODBC during installation? How? Configure setup.in in the
source setup?


Thanks!



Maneesh.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: hidding the "console" window + system global shortcut keys

[Richie Hindle]

[Gabriel]
> 2. Set global key biddings.

You can do this using ctypes:

http://groups.google.co.uk/groups?selm=mailman.929.1069345408.702.python-list%40python.org

-- 
Richie Hindle
[EMAIL PROTECTED]

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Iwan van der Kleyn]

Also, you keep talking about "the core python team" on the basis, it
would appear, of reading one document by Guido.  Have you bothered doing
a MINIMUM of homework, such as, looking at
http://www.amk.ca/diary/archives/cat_python.html
Well, you being a member of that core team (meaning nog an 
organisational unit, but the group of people doing the really hard job, 
getting Python to work. An excellent job at that :-) I can repect you 
if not branding me a lamer at least admonishing me for not coming up 
with a thorough factual statement. But like I stated: "ramblings", remember.

I'm not completely unknown with the workings of our species myself, 
though. Especially when discourse and policy is dictated by a select 
group of people (meaning: the one who actually create python, no 
criticism there) with final abritary powers for one indidual (again, no 
criticism), mindset *is* just as important as stated fact. Mindset will 
dictate future discourse and action.

And I do sense (reading planet python/this newsgroup) a mindset or at 
least a tendency by the people who really matter in these discussion to 
keep on adding features to the syntax; to add "structure" to Python. My 
personal preference would be to leave the language alone for a while and 
to improve its infrastructure.

Regards,
Iwan
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lambda as declarative idiom (was RE: what is lambda used for in real code?)

[Bengt Richter]

On Mon, 03 Jan 2005 18:54:06 GMT, Steven Bethard <[EMAIL PROTECTED]> wrote:

>Roman Suzi wrote:
>> I wish lambdas will not be deprecated in Python but the key to that is
>> dropping the keyword (lambda). If anybody could think of a better syntax for
>> lambdas _with_ arguments, we could develop PEP 312 further.
>
>Some suggestions from recent lambda threads (I only considered the ones 
>that keep lambda as an expression):
>
Just for reference, am I correct in assuming these are the equivalent
uses of lambda?:

 lambda a, b, c:f(a) + o(b) - o(c)
 lambda x: x * x
 lambda : x
 lambda *a, **k: x.bar(*a, **k)
 (lambda : x(*a, **k)) for x, a, k in funcs_and_args_list)

That last seems like it might need the default-arg-value hack: i.e.,
 (lambda x=x, a=a, k=k: x(*a, **k)) for x, a, k in funcs_and_args_list)


>* Args Before Expression *
>
>Nick Coghlan: def-to syntax [1]
>(def (a, b, c) to f(a) + o(b) - o(c))
>(def (x) to x * x)
>(def () to x)
>(def (*a, **k) to x.bar(*a, **k))
>((def () to x(*a, **k)) for x, a, k in funcs_and_args_list)
>
>Nick Coghlan: def-arrow syntax [1]
>(def (a, b, c) -> f(a) + o(b) - o(c))
>(def (x) -> x * x)
>(def () -> x)
>(def (*a, **k) -> x.bar(*a, **k))
>((def () -> x(*a, **k)) for x, a, k in funcs_and_args_list)
>
>Alex Martelli: def-as syntax [2]
>(def (a, b, c) as f(a) + o(b) - o(c))
>(def (x) as x * x)
>(def () as x)
>(def (*a, **k) as x.bar(*a, **k))
>((def () as x(*a, **k)) for x, a, k in funcs_and_args_list)
>
>Dave Benjamin: fun syntax [7]
>(fun(a, b, c): f(a) + o(b) - o(c))
>(fun(x): x * x)
>(fun(): x)
>(fun(*a, **k): x.bar(*a, **k))
>((fun(): x(*a, **k)) for x, a, k in funcs_and_args_list)
>
>
>* Expression Before Args *
>
>Robert Brewer: for (no-parens) syntax [3]
>(f(a) + o(b) - o(c) for a, b, c)
>(x * x for x)
>(x for ())
>(x.bar(*a, **k) for *a, **k)
>((x(*a, **k) for ()) for x, a, k in funcs_and_args_list)
>
>Nick Coghlan: for syntax [6]
>(f(a) + o(b) - o(c) for (a, b, c))
>(x * x for (x))
>(x for ())
>(x.bar(*a, **k) for (*a, **k))
>((x(*a, **k) for ()) for x, a, k in funcs_and_args_list)
>
>Nick Coghlan: def-from syntax [4]
>(def f(a) + o(b) - o(c) from (a, b, c))
>(def x * x from (x))
>(def x from ())
>(def x.bar(*a, **k) from (*a, **k))
>((def x(*a, **k) from ()) for x, a, k in funcs_and_args_list)
>
>Michael Spencer: from-args syntax [5]
>(f(a) + o(b) - o(c) from args(a, b, c))
>(x * x from args(x))
>(x from args())
>(x.bar(*a, **k) from args(*a, **k))
>((x(*a, **k) from args()) for x, a, k in funcs_and_args_list)
>
>Michael Spencer: for-args syntax [5]
>(f(a) + o(b) - o(c) for args(a, b, c))
>(x * x for args(x))
>(x for args())
>(x.bar(*a, **k) for args(*a, **k))
>((x(*a, **k) for args()) for x, a, k in funcs_and_args_list)
>
>
>So there's a bunch of ideas out there.  I don't know if any of them 
>could be overwhelmingly preferred over lambda.

Just thought of another, more concise and keywordless, expression-before-args 
syntax:
(:expression)(formalparams)# equivalent to lambda formalparams:expression

 (:f(a) + o(b) - o(c))(a, b, c)
 (:x*x)(X)
 (:x)()
 (:x.bar(*a, **k))(*a, **k)
 ((:x(*a, **k)() for x, a, k in funcs_and_args_list)
and with args default hack:
 ((:x(*a, **k)(x=x, a=a, k=k) for x, a, k in funcs_and_args_list)

I would have proposed (expression)(formalparams), but that is already legal ;-)


>
>Personally, I lean slightly towards the def-from syntax because it uses 
>the 'def' keyword to bring your attention to the fact that a function is 
>being defined, and it gives the expression precedence over the arglist, 
>which makes sense to me for an anonymous function, where (IMHO) the 
>expression is really the most important part of the declaration.
The syntax above panders to that ;-)

>
>OTOH, I think Michael Spencer's args() function, if implementable, could 
>have a lot of cool uses, like getting the arguments passed to next 
>within a generator.  (See the thread about that[8].)
>
Actually, I would rather have seen the function interface itself used for that, 
and
not have a scan for yields magically convert the normal function calling 
interface to
a generator factory interface. But we are past that, unless we invent something 
new.

E.g. if functions had an f.multicall() factory function that would return a 
generator
"next" function with the same interface as f but starting code execution at the 
start
the first time, and after yields on subsequent calls, then we could write

def f(x):
yield x+2
yield x*2
g = f.multicall()  # not currently available
[g(n) for n in (2,5)]

and get (untested)
[4, 10]

instead of as now having to write something like

 >>> def f(x):
 ... yield x[0]+2
 ... yield x[0]*2
 ...
 >>> x = ['ignored']
 >>> g = f(x).next
 >>> [g() for x[0] in (2,5)]
 [4, 10]

or wrapping with something more sugary.

>
>Steve
>
>[1]http://mail.python.org/pipermail/python-list/2004-December/256859.html
>[2]http://mail.python.org/pipermail/python-list/2004-December/256881.html
>[3]htt

Re: csh to Python

[Max M]

Nader Emami wrote:
Hello,
I am new in Python world, and would like to begin with
translate a csh file to a python script. Could somebody give
me an advise (documentation or web-site) where I can do that.

You are probably interrested in the os 6 os.path modules.
--
hilsen/regards Max M, Denmark
http://www.mxm.dk/
IT's Mad Science
--
http://mail.python.org/mailman/listinfo/python-list

Re: ODBC Connection on Windows XP

[Andrew MacIntyre]

On Mon, 3 Jan 2005, Greg Lindstrom wrote:

> I am running Python 2.3 on Windows XP and am trying to connect to an
> ODBC datasource.  I have done this many times on this same box but this
> time I get an error message saying
>
> dbi.operation-error: [WSOCK32.DLL]Connection refused, is the host
> listener running? (#10061) in LOGIN
>
> Not having seen this before, and having used the odbc module for about a
> year now, I'm at a quandary; what does this mean and what do I do to fix it?

Exactly what it says... the host you're trying to connect to has refused
your connection attempt (at the TCP level).  At a guess, the database is
down.

-
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: [EMAIL PROTECTED]  (pref) | Snail: PO Box 370
[EMAIL PROTECTED] (alt) |Belconnen ACT 2616
Web:http://www.andymac.org/   |Australia
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Lambda as declarative idiom (was RE: what is lambda used for in real code?)

[Roman Suzi]

On Mon, 3 Jan 2005, Steven Bethard wrote:

> Roman Suzi wrote:
> > I wish lambdas will not be deprecated in Python but the key to that is
> > dropping the keyword (lambda). If anybody could think of a better syntax for
> > lambdas _with_ arguments, we could develop PEP 312 further.
>
> Some suggestions from recent lambda threads (I only considered the ones
> that keep lambda as an expression):
>
> * Args Before Expression *
>
> Nick Coghlan: def-to syntax [1]
> (def (a, b, c) to f(a) + o(b) - o(c))
> (def (x) to x * x)

Wow! Is there any wiki-page these could be put on?

By the way, I think to satisfy least-surprise principle, our declarative
idiom must be compatible with type declarations GvR is planning for Python
3.0. This way Python will have ONE style for declarations, be it
type declarations, logical declarations or database-queries, etc.

This means, that there is a need for a LISP's quote, when code is only
written and parsed but may be processed not only by Python interpreter
itself but by any user-made interpreter. For example, type-checker,
cursor.execute, lazy-Python-subinterpreter, DOM-manipulator etc.

I do not know how it could be done syntactically, but it could be done
if thought about long enough.

Lambdas is one of the ways, arguably not the most pleasant one for
a "quote".

Maybe this is too outlandish, but I see lambdas as a "quote" mechanism,
which presents a possibility to postpone (precisely control, delegate)
evaluation. That is, an ovehead for lambda must be much lower but at the
same time visible to the programmer:

 d = a + (lambda x, y: x+ y)(3, 4)

if this expression is to be viewed in hypotetical syntax-highlighting
editor, "(lambda x, y: x+ y)" need to be painted with another color
than the rest of the expression, as it represents defining part of the
expression, not the part which is being evaluated right away.

What if we deprecate ` in it's repr() function and reserve it for
inline lambdas (for Python 3.0, of course):

 d = a + (` x, y: x+y) (3, 4)

Thus, implicit lambdas will be one more symbol, e.g.

(`: None)

instead of

(: None)

What does Guido think? ;)

Sincerely yours, Roman A.Suzi
-- 
 - Petrozavodsk - Karelia - Russia - mailto:[EMAIL PROTECTED] -

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Ville Vainio]

> "Iwan" == Iwan van der Kleyn <[EMAIL PROTECTED]> writes:

Iwan> And then I read the following sentence by Van Rossum:

Iwan> "In order to make type inferencing a little more useful, I'd
Iwan> like to restrict certain forms of extreme dynamic behavior
Iwan> in Python"

Iwan> In the end, it's mindset which counts. And I think that
Iwan> mindset is going to be determine the way foreward for
Iwan> Python: more features, increased complexity, less
Iwan> dynamism. Lots of syntax crud, without addressing the need
Iwan> to improve the infrastructure around the language.

What form of extreme dynamic behaviour have you been using lately? Do
you really think it's more worthwhile than the benefits provided by
type inference, least of which isn't the ability by IDEs to provide
you accurate code completion.

Also, Python is not a monolithic entity. Guido certainly isn't going
to write a better IDE for Python, so the time used on language
features isn't removed from improving the infrastructure around the
language.

-- 
Ville Vainio   http://tinyurl.com/2prnb
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How do I make Windows Application with Python ?

[Fuzzyman]

You need py2exe to bundle applications so they can be used on machines
without python. When you do that you have a choice of whether or not
your application should have a console box or not. In order to use
buttons and other widgets you will need to choose a GUI toolkit. I
recommend starting with Tkinter - but others would recommend wxPython.
Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[Kent Johnson]

Alex Martelli wrote:
Roy Smith <[EMAIL PROTECTED]> wrote:

Stefan Axelsson <[EMAIL PROTECTED]> wrote:
Yes, ignoring most of the debate about static vs. dynamic typing, I've
also longed for 'use strict'.
You can use __slots__ to get the effect you're after.  Well, sort of; it
only works for instance variables, not locals.  And the gurus will argue
that __slots__ wasn't intended for that, so you shouldn't do it.

There's a simple, excellent recipe by Michele Simionato, on both the
online and forthcoming 2nd edition printed Cookbook, showing how to do
that the right way -- with __setattr__ -- rather than with __slots__ .
The recipe is here (it took me a few minutes to find it, I found the title 
misleading):
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/252158
Kent
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Paul Rubin]

Ville Vainio <[EMAIL PROTECTED]> writes:
> Also, Python is not a monolithic entity. Guido certainly isn't going
> to write a better IDE for Python, so the time used on language
> features isn't removed from improving the infrastructure around the
> language.

There aren't THAT many people working on Python.  Any time spent on
feature X does tend to divert resources from feature Y.

I think there should be a moratorium on nontrivial language changes
(as opposed to library improvements) until PyPy is fully deployed.
Too much of Python as we know it today is shaped by the weirdness of
CPython.  We ought to be able to get away from that.
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Python evolution: Unease

[Batista, Facundo]

Title: RE: Python evolution: Unease





[Iwan van der Kleyn]


#- need: a better standard ide, an integrated db interface with 
#- a proper 
#- set of db drivers (!!), a better debugger, a standard widget/windows 
#- toolkit, something akin to a standard for web programming, better 
#- documentation, a standard lib which is better organized, a 
#- formalized 
#- set of protocols and patterns for program construction. And an 
#- interpreter which is fast enough to avoid using C or Pyrex in most 
#- obvious cases.


Let's take one by one:


- IDE: Better than what? Than IDLE? Than Eclipse? Than SPE? Than Pythonwin?


- Integrated DB interface with a proper set of db drivers (what means the "!!"?): What do you mean with an integrated db interface? An standard API to access different DB engines? Something like the Database API specification (http://www.python.org/topics/database/DatabaseAPI-2.0.html)? There's a SIG on DB at http://www.python.org/sigs/db-sig/ you may want to look at. Regarding drivers, to what DB do you miss one?

- Debugger: Again, better than what? I use the debugger in IDLE and it's pretty ok.


- Standard widget/windows toolkit: More standard than Tk?


- Something akin to a standard for web programming: specifically?


- Better documentation: Did you find *any* issue in the docs? And why you didn't post a bug on that?


- Better organization of the std lib: What do you propose (specifically)? Please, in your proposal, take in consideration migration plans and how the migration affect actual systems. And of course, why the new organization is better than the old one. BTW, I also think that it should be better organized, but don't know how.

- a formalized set of protocols and patterns for program construction: a what?


- an interpreter which is fast enough to avoid using C or Pyrex in most obvious cases: CPython is More Than Fast Enough. In which obvious cases it's not enough for you?

Don't misinterpret this response. I know it was a rambling. But *maybe* you have something to contribute to Python development, even good ideas only and no work.

.    Facundo


Bitácora De Vuelo: http://www.taniquetil.com.ar/plog
PyAr - Python Argentina: http://pyar.decode.com.ar/



  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ADVERTENCIA.


La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley.

Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo.

Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada.

Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje.

Muchas Gracias.



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: input record sepArator (equivalent of "$|" of perl)

[Steve Holden]

Dennis Lee Bieber wrote:
On Mon, 03 Jan 2005 19:14:54 -0500, Steve Holden <[EMAIL PROTECTED]>
declaimed the following in comp.lang.python:

Plus the builders quite routinely ask suppliers for things like "a meter 
of two (inches) by four (inches)". They don;t care that they're getting 
the closest metric equivalent, to them a 2 x 4 is still a 2 x 4.

And what do they get? A normal finished 2x4 runs about 1.5x3.5
inches...
A 1x4 is 0.75x3.5
Who knows, but htey don;t complain about it. In the UK also the sizes 
refer to the rough cut, before finish planing.

regards
 Steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
--
http://mail.python.org/mailman/listinfo/python-list

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30)

[michele . simionato]

Holger:

> FWIW, i added the recipe back to the online cookbook. It's not
perfectly
> formatted but still useful, i hope.

>   http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/361742

Uhm... on my system I get:

>>> german_ae = unicode('\xc3\xa4', 'utf8')
>>> print german_ae # dunno if it will appear right on Google groups
ä

>>> german_ae.decode('latin1')
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in
position 0: ordinal not in range(128)
?? What's wrong?

Michele Simionato

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Ville Vainio]

> "Paul" == Paul Rubin  writes:

Paul> Ville Vainio <[EMAIL PROTECTED]> writes:

>> Also, Python is not a monolithic entity. Guido certainly isn't
>> going to write a better IDE for Python, so the time used on
>> language features isn't removed from improving the
>> infrastructure around the language.

Paul> There aren't THAT many people working on Python.  Any time
Paul> spent on feature X does tend to divert resources from
Paul> feature Y.

But the people working on wxPython, pygtk, pyqt, pydev, whatever, are
largely not the same guys that commit stuff to CPython CVS.

Paul> fully deployed.  Too much of Python as we know it today is
Paul> shaped by the weirdness of CPython.  We ought to be able to
Paul> get away from that.

Type declarations are a feature that might benefit IronPython and
Jython more than they would CPython.

-- 
Ville Vainio   http://tinyurl.com/2prnb
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Paul Rubin]

Ville Vainio <[EMAIL PROTECTED]> writes:
> But the people working on wxPython, pygtk, pyqt, pydev, whatever, are
> largely not the same guys that commit stuff to CPython CVS.

Right, but for that reason, they don't count as being working on
Python.

> Type declarations are a feature that might benefit IronPython and
> Jython more than they would CPython.

CPython seems to be what drives quite a few language design decisions.
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Python evolution: Unease

[Roman Suzi]

On Tue, 4 Jan 2005, Batista, Facundo wrote:

Maybe OP doesn't yet fully comprehend the ways of Python universe?

As for his claims, I am quite surprised that Python lacks
something in the docs.

Concerning better hierarchy in the standard library, it is interesting
that there are some movements in this direction: xml package,
email package, etc. Probably Iwan thinks that letting more
"hierachiesness" into std lib Python will be "cleaner".
Yes, it will probably look "more organized" this way, but
I do not like the idea:

 import time.time
 import time.calendar
 ...
 import web.url.openers
 import net.http
 ...
 import datatypes.string
 import textprocessing.re

etc.


> [Iwan van der Kleyn]
>
> #- need: a better standard ide, an integrated db interface with
> #- a proper
> #- set of db drivers (!!), a better debugger, a standard widget/windows
> #- toolkit, something akin to a standard for web programming, better
> #- documentation, a standard lib which is better organized, a
> #- formalized
> #- set of protocols and patterns for program construction. And an
> #- interpreter which is fast enough to avoid using C or Pyrex in most
> #- obvious cases.
>
> Let's take one by one:
>
> - IDE: Better than what? Than IDLE? Than Eclipse? Than SPE? Than Pythonwin?
>
> - Integrated DB interface with a proper set of db drivers (what means the
> "!!"?): What do you mean with an integrated db interface? An standard API to
> access different DB engines? Something like the Database API specification
> (http://www.python.org/topics/database/DatabaseAPI-2.0.html)? There's a SIG
> on DB at http://www.python.org/sigs/db-sig/ you may want to look at.
> Regarding drivers, to what DB do you miss one?
>
> - Debugger: Again, better than what? I use the debugger in IDLE and it's
> pretty ok.
>
> - Standard widget/windows toolkit: More standard than Tk?
>
> - Something akin to a standard for web programming: specifically?
>
> - Better documentation: Did you find *any* issue in the docs? And why you
> didn't post a bug on that?
>
> - Better organization of the std lib: What do you propose (specifically)?
> Please, in your proposal, take in consideration migration plans and how the
> migration affect actual systems. And of course, why the new organization is
> better than the old one. BTW, I also think that it should be better
> organized, but don't know how.
>
> - a formalized set of protocols and patterns for program construction: a
> what?
>
> - an interpreter which is fast enough to avoid using C or Pyrex in most
> obvious cases: CPython is More Than Fast Enough. In which obvious cases it's
> not enough for you?
>
> Don't misinterpret this response. I know it was a rambling. But *maybe* you
> have something to contribute to Python development, even good ideas only and
> no work.
>
> .Facundo

Sincerely yours, Roman A.Suzi
-- 
 - Petrozavodsk - Karelia - Russia - mailto:[EMAIL PROTECTED] -

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30)

[Stephan Diehl]

On Tue, 04 Jan 2005 05:43:32 -0800, michele.simionato wrote:

> Holger:
> 
>> FWIW, i added the recipe back to the online cookbook. It's not
> perfectly
>> formatted but still useful, i hope.
> 
>>   http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/361742
> 
> Uhm... on my system I get:
> 
 german_ae = unicode('\xc3\xa4', 'utf8')
 print german_ae # dunno if it will appear right on Google groups
> ä
> 
 german_ae.decode('latin1')
> Traceback (most recent call last):
> File "", line 1, in ?
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in
> position 0: ordinal not in range(128)
> ?? What's wrong?

I'd rather use german_ae.encode('latin1')
 ^^

which returns '\xe4'.
> 
> Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: why does UserDict.DictMixin use keys instead of __iter__?

[Steven Bethard]

Nick Coghlan wrote:
Steven Bethard wrote:
Sorry if this is a repost -- it didn't appear for me the first time.
So I was looking at the Language Reference's discussion about emulating
container types[1], and nowhere in it does it mention that .keys() is
part of the container protocol.  Because of this, I would assume that to
use UserDict.DictMixin correctly, a class would only need to define
__getitem__, __setitem__, __delitem__ and __iter__.  So why does
UserDict.DictMixin require keys() to be defined?

Because it's a DictMixin, not a ContainerMixin?
"Containers usually are sequences (such as lists or tuples) or mappings 
(like dictionaries)".

.keys() is definitely part of the standard dictionary interface, and not 
something the mixin can derive from the generic container methods.
Why is that?  Isn't keys derivable as:
def keys(self):
return list(self)
if __iter__ is defined?
Steve
--
http://mail.python.org/mailman/listinfo/python-list

Re: Problem remotely shutting down a windows computer with python

[Tim G]

> I have a problem when using the python script found here:
>
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/360649
>
> It is a script to remotely shutdown a windows computer.  When I use
it,
> the computer shuts down, but doesn't power off like with a regular
> shutdown. It stays on the "Safe to power off" screen and I have to
push
> the power button to actually power off.  Anyone know why this happens
> with this script?  Thanks for any help.
>
> Eric

I see that others have answered the question
pretty completely, but just to add the obligatory
WMI solution:
[ assumes you're using the wmi module from
http://tgolden.sc.sabren.com/python/wmi.html ]



import wmi
c = wmi.WMI (computer="other_machine", privileges=["RemoteShutdown"])
os = c.Win32_OperatingSystem (Primary=1)[0]
os.Win32Shutdown (Flags=12)


The Flags=12 bit should shut down all the way.

TJG

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Istvan Albert]

Iwan van der Kleyn wrote:
And I do sense (reading planet python/this newsgroup) a mindset or at 
least a tendency by the people who really matter in these discussion to 
keep on adding features to the syntax; to add "structure" to Python. My 
personal preference would be to leave the language alone for a while and 
to improve its infrastructure.
In all honesty this:
http://www.artima.com/weblogs/viewpost.jsp?thread=86641
scares me too.  Reminds me of Larry Wall's writings on Perl 6
that make me tune out fairly quickly. I don't have the kind of
problems that the these features will solve so I can't relate
to them at all.
But others might do. Especially when using python in an environment
where enforcing a strict contract is important. But if python
were to become overly complicated I'll find something else.
Three years ago I have not not used python at all, now I'm
using it for everything.
Languages should evolve with time, adapt to the needs
of its users. Sometimes that means that in some areas
it might feel worse. But it could also mean that the
problem is with us, so it would be unfair to spend effort
towards holding back this evolution just because
we don't need it.
Istvan.
PS. why can't decorators solve this optional type checking
problem? I clearly remember this as being one of the
selling points for having decorators in the first place...
--
http://mail.python.org/mailman/listinfo/python-list

Re: why does UserDict.DictMixin use keys instead of __iter__?

[Steven Bethard]

John Machin wrote:
Steven Bethard wrote:
So I was looking at the Language Reference's discussion about
emulating container types[1], and nowhere in it does it mention that
.keys() is part of the container protocol.
I don't see any reference to a "container protocol".
Sorry, I extrapolated "container protocol" from this statement:
"Containers usually are sequences (such as lists or tuples) or mappings 
(like dictionaries), but can represent other containers as well. The 
first set of methods is used either to emulate a sequence or to emulate 
a mapping"

and the fact that there is a "sequence protocol" and a "mapping protocol".
But all I was really reading from this statement was that the "first set 
of methods" (__len__, __getitem__, __setitem__, __delitem__ and 
__iter__) were more integral than the second set of methods (keys(), 
values(), ...).


What I do see is
(1) """It is also recommended that mappings provide the methods keys(),
..."""
You skipped the remaining 13 methods in this list:
"It is also recommended that mappings provide the methods keys(), 
values(), items(), has_key(), get(), clear(), setdefault(), iterkeys(), 
itervalues(), iteritems(), pop(), popitem(), copy(), and update() 
behaving similar to those for Python's standard dictionary objects."

This is the "second set of methods" I mentioned above.  I don't 
understand why the creators of UserDict.DictMixin decided that keys(), 
from the second list, is more important than __iter__, from the first list.


Because of this, I would assume that to
use UserDict.DictMixin correctly, a class would only need to define
__getitem__, __setitem__, __delitem__ and __iter__.

So I can't see why would you assume that, given that the docs say in
effect "you supply get/set/del + keys as the building blocks, the
DictMixin class will provide the remainder". This message is reinforced
in the docs for UserDict itself.
Sorry, my intent was not to say that I didn't know from the docs that 
UserDict.DictMixin required keys().  Clearly it's documented.  My 
question was *why* does it use keys()?  Why use keys() when keys() can 
be derived from __iter__, and __iter__ IMHO looks to be a more basic 
part of the mapping protocol.

In any case, isn't UserDict past history? Why are you mucking about
with it?
UserDict is past history, but DictMixin isn't.  As you note, DictMixin 
is even mentioned in the section of the Language Reference that we're 
discussing:

"The UserDict module provides a DictMixin class to help create those 
methods from a base set of __getitem__(), __setitem__(), __delitem__(), 
and keys()."

Steve
--
http://mail.python.org/mailman/listinfo/python-list

Re: HTTP GET request with basic authorization?

[Fuzzyman]

There's example code with discussion at :
http://www.voidspace.org.uk/atlantibots/recipebook.html#auth
Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

-- 
http://mail.python.org/mailman/listinfo/python-list

python intergration bus ?

[Tonino]

Hi,

Just an interested question - I friend is testing a few JAVA
intergration bus's that will be used to intergrate his companies
services - I was wondering if there was a python intergration bus ?
other than maybe Pyro ?



Thanks
Tonino

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Lambda as declarative idiom (was RE: what is lambda used for in real code?)

[Steven Bethard]

Bengt Richter wrote:
On Mon, 03 Jan 2005 18:54:06 GMT, Steven Bethard <[EMAIL PROTECTED]> wrote:

Roman Suzi wrote:
I wish lambdas will not be deprecated in Python but the key to that is
dropping the keyword (lambda). If anybody could think of a better syntax for
lambdas _with_ arguments, we could develop PEP 312 further.
Some suggestions from recent lambda threads (I only considered the ones 
that keep lambda as an expression):

Just for reference, am I correct in assuming these are the equivalent
uses of lambda?:
 lambda a, b, c:f(a) + o(b) - o(c)
 lambda x: x * x
 lambda : x
 lambda *a, **k: x.bar(*a, **k)
 (lambda : x(*a, **k)) for x, a, k in funcs_and_args_list)
Yeah, I believe that was the intention, though I stole the examples from 
[1].

That last seems like it might need the default-arg-value hack: i.e.,
 (lambda x=x, a=a, k=k: x(*a, **k)) for x, a, k in funcs_and_args_list)
Good point.
Steve
--
http://mail.python.org/mailman/listinfo/python-list

Reaching the real world

[Fuzzyman]

I have a friend who would like to move and program lights and other
electric/electro-mechanical devices by computer. I would like to help -
and needless to say Python would be an ideal language for the
'programmers interface'.

What I'd like is an electronic interface that connects to several
relays and a python extension module to switch on and off the relays.
I've had a quick google and can't see anything too similar to what I
want. pyro (python robotics) seems to require expensive (relatively)
robotic equipment.

Does anyone know anything *similar* to what I have in mind, or have
alternative suggestions ?
Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to access database?

[Swaroop C H]

Florian Lindner wrote:
Hello,
AFAIK python has a generic API for database access which adapters are
supposed to implement. How can I found API documentation on the API?
I found these pages useful when learning the DB API:
* http://www.kitebird.com/articles/pydbapi.html
* http://www.amk.ca/python/writing/DB-API.html
HTH,
--
Swaroop C H
Blog: http://www.swaroopch.info/
--
http://mail.python.org/mailman/listinfo/python-list

Re: How do I make Windows Application with Python ?

[BOOGIEMAN]

On Mon, 03 Jan 2005 19:56:10 -0600, Rob Emmons wrote:

> I believe also if you want to use MS Visual Studio -- Active State sells
> python programming tools that plug into MS Visual Studio if you want to do
> that.  I've not tried these so I don't know how they work or if they are
> any good.

Thanks all for very detailed answers. BTW I tried this one but it seems
that it doesn't use VS'es visual designer. Also it doesn't have "build"
option so it is basicly only usefull to higlight Python syntax.
Active Sate Komodo looks like much better choice
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[Jacek Generowicz]

[EMAIL PROTECTED] (Alex Martelli) writes:

> I've always liked the (theoretical) idea that assertions (including of
> course contracts) could be used as axioms used to optimize generated
> code, rather than (necessarily) as a runtime burden.  E.g. (and I don't
> know of any implementation of this concept, mind you), inferring (e.g.
> from such assertions) that x>=0, and that y<0, the compiler could simply
> cut away a branch of dead code guarded by "if x warning, in this case;-)...

A few months ago, a troll challenged the denizens of comp.lang.lisp to
write a Lisp implementation of some some code which he posted in C++,
which would be competitive in terms of speed with his C++
version. The c.l.lers duly obliged, and, IIRC, it so happened that the
improvement that made the Lisp version overtake the C++ one was the
declaration of some variable to be of type "floating point number in
the range 0 to two Pi".

Of course, in CL type declarations are not contracts, but promises to
the compiler ... but it's still an examlpe of a situation where more
specific type information allowed the compiler to produce more
efficient code, in practice.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Aahz]

In article <[EMAIL PROTECTED]>,
 <[EMAIL PROTECTED]> wrote:
>
>Maybe a PSF grant would help? I guess this has been considered ...

The first three PSF grants were all in some way not directly related to
changing the core language.  One was for a library, one for improving
Jython, and one for improving docs.  Giving the PSF more money increases
the chances for additional work.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing."  --Alan Perlis
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Hlelp clean up clumpsy code

[It's me]

Thanks, Steve and Nick.

Yes, that's what I need to do.   I didn't know it's call "flattening" a list
structure but that's precisely what I needed to do.

Steve,

I am using 2.3 and so I will go with Nick's version.

Thanks to both for helping.


"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> It's me wrote:
> > Another newbie question.
> >
> > There must be a cleaner way to do this in Python:
> >
> >  section of C looking Python code 
> > a = [[1,5,2], 8, 4]
> > a_list = {}
> > i = 0
> > for x in a:
> > if isinstance(x, (int, long)):
> > x = [x,]
> > for w in [y for y in x]:
> > i = i + 1
> > a_list[w] = i
> > print a_list
> > #
> >
> > The code prints what I want but it looks so "C-like".  How can I make it
> > more Python like?
>
> Firstly, calling your dictionary "a_list" is evil. . .
>
> Secondly, explaining what you want the code to do in English is handy when
> asking for help cleaning up code (since we then know which features are
> deliberate, and which are accidental implementation artificacts).
>
> If I'm reading the code correctly, you want to flatten a data structure
which
> may contain either substructures or actual elements.
>
> A custom generator will do nicely:
>
> Py> def flatten(seq):
> ...   for x in seq:
> ... if hasattr(x, "__iter__"):
> ...   for y in flatten(x):
> ... yield y
> ... else:
> ...   yield x
> ...
> Py> data = [[1,5,2],8,4]
> Py> val_to_pos = {}
> Py> for i, x in enumerate(flatten(data)):
> ...   val_to_pos[x] = i + 1
> ...
> Py> print val_to_pos
> {8: 4, 1: 1, 2: 3, 4: 5, 5: 2}
>
> Not any shorter, but this version works correctly for any leaf elements
which
> don't supply __iter__ (e.g. strings), and internal elements which do (e.g.
> tuples) and the depth is limited only by the maximum level of recursion.
Don't
> try to flatten a circular structure, though :)
>
> You may not even need to write the generator, since if you have Tkinter,
that
> already supplies a near-equivalent function:
>
> Py> from Tkinter import _flatten as flatten
> Py> data = [[1,5,2],8,4]
> Py> val_to_pos = {}
> Py> for i, x in enumerate(flatten(data)):
> ...   val_to_pos[x] = i + 1
> ...
> Py> print val_to_pos
> {8: 4, 1: 1, 2: 3, 4: 5, 5: 2}
>
> It even works with strings as leaf elements:
>
> Py> data = [["abc","def",2],8,"xyz"]
> Py> flatten(data)
> ('abc', 'def', 2, 8, 'xyz')
>
> Cheers,
> Nick.
>
> -- 
> Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
> ---
>  http://boredomandlaziness.skystorm.net


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30)

[Skip Montanaro]

michele> BTW what's the difference between .encode and .decode ?

I started to answer, then got confused when I read the docstrings for
unicode.encode and unicode.decode:

>>> help(u"\xe4".decode)
Help on built-in function decode:

decode(...)
S.decode([encoding[,errors]]) -> string or unicode

Decodes S using the codec registered for encoding. encoding defaults
to the default encoding. errors may be given to set a different error
handling scheme. Default is 'strict' meaning that encoding errors raise
a UnicodeDecodeError. Other possible values are 'ignore' and 'replace'
as well as any other name registerd with codecs.register_error that is
able to handle UnicodeDecodeErrors.

>>> help(u"\xe4".encode)
Help on built-in function encode:

encode(...)
S.encode([encoding[,errors]]) -> string or unicode

Encodes S using the codec registered for encoding. encoding defaults
to the default encoding. errors may be given to set a different error
handling scheme. Default is 'strict' meaning that encoding errors raise
a UnicodeEncodeError. Other possible values are 'ignore', 'replace' and
'xmlcharrefreplace' as well as any other name registered with
codecs.register_error that can handle UnicodeEncodeErrors.

It probably makes sense to one who knows, but for the feeble-minded like
myself, they seem about the same.

I'd be happy to add a couple examples to the string methods section of the
docs if someone will produce something simple that makes the distinction
clear.

Skip

-- 
http://mail.python.org/mailman/listinfo/python-list

Unicode universe (was Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30))

[Aahz]

In article <[EMAIL PROTECTED]>,
 <[EMAIL PROTECTED]> wrote:
>
>BTW what's the difference between .encode and .decode ?
>(yes, I have been living in happy ASCII-land until now ... ;)

Here's the stark simple recipe: when you use Unicode, you *MUST* switch
to a Unicode-centric view of the universe.  Therefore you encode *FROM*
Unicode and you decode *TO* Unicode.  Period.  It's similar to the way
floating point contaminates ints.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing."  --Alan Perlis
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Paul Rubin]

Roman Suzi <[EMAIL PROTECTED]> writes:
> As for his claims, I am quite surprised that Python lacks
> something in the docs.

Python is lacking plenty in the docs.  Care to figure out from the
docs how tkinter works?  That's not explained anywhere at all, except
in some off-site resources and in some printed books.  Even some
language features like class methods and slots are explained only in
PEP's and release notes, instead of in the language manual where you'd
expect to find them since they're part of the language.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Lambda as declarative idiom (was RE: what is lambda used for in real code?)

[Steven Bethard]

Roman Suzi wrote:
On Mon, 3 Jan 2005, Steven Bethard wrote:

Roman Suzi wrote:
I wish lambdas will not be deprecated in Python but the key to that is
dropping the keyword (lambda). If anybody could think of a better syntax for
lambdas _with_ arguments, we could develop PEP 312 further.
Some suggestions from recent lambda threads (I only considered the ones
that keep lambda as an expression):
Wow! Is there any wiki-page these could be put on?
It's now on:
http://www.python.org/moin/AlternateLambdaSyntax
and I added Bengt Richter's and your recent suggestions.
Steve
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[michele . simionato]

Aahz:

> The first three PSF grants were all in some way not directly related
to
> changing the core language. One was for a library, one for improving
> Jython, and one for improving docs. Giving the PSF more money
increases
> the chances for additional work.

Here is the link you forgot to post ;-)

http://www.python.org/psf/grants/

The one about the docs seems more about teaching scientists how to use
Python.

   Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reaching the real world

[Thomas Bartkus]

"Fuzzyman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I have a friend who would like to move and program lights and other
> electric/electro-mechanical devices by computer. I would like to help -
> and needless to say Python would be an ideal language for the
> 'programmers interface'.
>
> What I'd like is an electronic interface that connects to several
> relays and a python extension module to switch on and off the relays.
> I've had a quick google and can't see anything too similar to what I
> want. pyro (python robotics) seems to require expensive (relatively)
> robotic equipment.

Loosely, what you are looking for is Data Acquisition (DAQ) , Digital I/O,
and control that you can do from your pc. Those are the keywords you want to
google.

Look at www.ni.com and poke around. They will have some introductory
material.
Look at www.circuitcellar.com .  It may look a bit overwhelming at first but
look at the ads for pc equipment.  These should also lead you to some
tutorials.

You are looking for simple digital output. You can use an existing serial or
parallel port with a bit of external hardware from radio shack to control
relays on the cheap.
OR
You can purchase a Digital I/O adaptor that will plug into your computer bus
and give you outputs to control your  relays.  You will also get
instructions and some software to interface (talk!) to the adaptor.
Typically you will read and write to the I/O ports on your computer to flip
the switches.
   OR perhaps the easiest and most effective
These would be smart devices that talk to your Python (or whatever!)
software via the serial port. You would throw simple string commands (eg
"ChannelB ON") at the serial port and the microprocessor based controller
will turn on the appropriate relay.

Your challenge from Python will be to control the computers I/O ports or to
communicate with one of the serial ports.  I'm sure someone else will point
to libraries that will help you with this.

Much *much* more but you have to start somewhere :-)
Thomas Bartkus


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode universe (was Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30))

[Skip Montanaro]

aahz> Here's the stark simple recipe: when you use Unicode, you *MUST*
aahz> switch to a Unicode-centric view of the universe.  Therefore you
aahz> encode *FROM* Unicode and you decode *TO* Unicode.  Period.  It's
aahz> similar to the way floating point contaminates ints.

That's what I do in my code.  Why do Unicode objects have a decode method
then?

Skip

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30)

[michele . simionato]

Yep, I did the same and got confused :-/

Michele

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30)

[michele . simionato]

Stephan:

> I'd rather use german_ae.encode('latin1')
^^
> which returns '\xe4'.

uhm ... then there is a misprint in the discussion of the recipe;
BTW what's the difference between .encode and .decode ?
(yes, I have been living in happy ASCII-land until now ... ;)
I should probably ask for an unicode primer, I have found the
one by Marc André Lemburg
http://www.reportlab.com/i18n/python_unicode_tutorial.html
and I am reading it right now.


 Michele Simionato

--
http://mail.python.org/mailman/listinfo/python-list

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30)

[Thomas Heller]

Skip Montanaro <[EMAIL PROTECTED]> writes:

> michele> BTW what's the difference between .encode and .decode ?
>
> I started to answer, then got confused when I read the docstrings for
> unicode.encode and unicode.decode:
>
> >>> help(u"\xe4".decode)
> Help on built-in function decode:
>
> decode(...)
> S.decode([encoding[,errors]]) -> string or unicode
>
> Decodes S using the codec registered for encoding. encoding defaults
> to the default encoding. errors may be given to set a different error
> handling scheme. Default is 'strict' meaning that encoding errors 
> raise
> a UnicodeDecodeError. Other possible values are 'ignore' and 'replace'
> as well as any other name registerd with codecs.register_error that is
> able to handle UnicodeDecodeErrors.
>
> >>> help(u"\xe4".encode)
> Help on built-in function encode:
>
> encode(...)
> S.encode([encoding[,errors]]) -> string or unicode
>
> Encodes S using the codec registered for encoding. encoding defaults
> to the default encoding. errors may be given to set a different error
> handling scheme. Default is 'strict' meaning that encoding errors 
> raise
> a UnicodeEncodeError. Other possible values are 'ignore', 'replace' 
> and
> 'xmlcharrefreplace' as well as any other name registered with
> codecs.register_error that can handle UnicodeEncodeErrors.
>
> It probably makes sense to one who knows, but for the feeble-minded like
> myself, they seem about the same.

It seems also the error messages aren't too helpful:

>>> "ä".encode("latin-1")
Traceback (most recent call last):
  File "", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0x84 in position 0: ordinal 
not in range(128)
>>>

Hm, why does the 'encode' call complain about decoding?

Why do string objects have an encode method, and why do unicode objects
have a decode method, and what does this error message want to tell me:

>>> u"ä".decode("latin-1")
Traceback (most recent call last):
  File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0: 
ordinal not in range(128)
>>>

Thomas
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Skip Montanaro]

Paul> Care to figure out from the docs how tkinter works?  That's not
Paul> explained anywhere at all, except in some off-site resources and
Paul> in some printed books.  Even some language features like class
Paul> methods and slots are explained only in PEP's and release notes,
Paul> instead of in the language manual where you'd expect to find them
Paul> since they're part of the language.

Start writing (or reorganizing).  Folks, this is open source.  I'm sure by
the traffic on the list most people here know how to write.  In the case of
Tkinter, you should probably get the okay of the authors of various external
docs before incorporating them into the Python docs, but note that several
Tkinter-related documents are referenced directly from the Tkinter module
docs:

Python Tkinter Resources
The Python Tkinter Topic Guide provides a great deal of information
on using Tk from Python and links to other sources of information on
Tk. 

An Introduction to Tkinter
Fredrik Lundh's on-line reference material.

Tkinter reference: a GUI for Python
On-line reference material.

Tkinter for JPython
The Jython interface to Tkinter.

Python and Tkinter Programming
The book by John Grayson (ISBN 1-884777-81-3).

This being the Internet and all, it's not clear that referencing external
documentation is somehow worse than incorporating it directly into the
distribution.

As for stuff that exists in PEPs and release notes, they should already all
have the necessary copyright (either they were placed in the public domain
or they are already part of the Python distribution) to allow you do just
check out a CVS tree, make the necessary edits and either check the files
back in or submit a patch to SourceForge.

In the documentation arena, I think more thought should probably be given to
producing online docs that can be directly annotated, thus further reducing
the barrier to more complete documentation (and more updates).  Take a look
at latex2html, propose or implement changes, or just rewrite the damn thing
in Python.  I think latex2html is probably a recurring nightmare for Fred
Drake.

Skip
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How can engineers not understand source-code control?

[Cameron Laird]

In article <[EMAIL PROTECTED]>,
Mark Carter  <[EMAIL PROTECTED]> wrote:
.
.
.
>True story: when I began working for my current employer, there was a 
>guy there doing some work with a spreadsheet. He was given two weeks to 
.
[tale of atrocity and woe]
.
.
>cell formulae. The rationale behind this is that VBA is too hard for 
>most people to understand, whereas formulae are easier to understand. 
.
.
.
Well *that* certainly made my morning unpleasant.

I think the point to take away has something to do with maturity
or judgment or one of those other difficult qualities.  Some of
this stuff--"formulae are easy to understand", "you don't need
programmers, you just enter what you want the machine to do",
"we'll wage war on terrorists by *becoming* terrorists", "Micro-
soft has spent more on 'security' than any other vendor"--*sounds*
like a useful guide to action.  A hard part of our responsibility,
though, is articulating for decision-makers that these superficial
simplificities truly are superficial, and that they lead to 
monstrous costs that are hard for "civilians" to anticipate.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reaching the real world

[Gregor Horvath]

Hi,
I have just written a python module to program the M232 measurement unit 
from elv.
It has 8 digital I/O and 6 analog ports (0-5V). Works fine, although it 
is a little bit slow (0,2 s to measure)
Furthermore the digital ports do not have enough power to switch a relay 
directly, I had to do it with additional transistors.
It controls my heating together with a python program an a eletric motor 
/ gearbox and some sensors.

german store:
http://www.elv.de/
Type M232 into the search field.
english:
http://www.elv.de/shopping/elvcom/
If you are intersted in the python code, just drop a note.
--
Greg
Fuzzyman wrote:
I have a friend who would like to move and program lights and other
electric/electro-mechanical devices by computer. I would like to help -
and needless to say Python would be an ideal language for the
'programmers interface'.
What I'd like is an electronic interface that connects to several
relays and a python extension module to switch on and off the relays.
I've had a quick google and can't see anything too similar to what I
want. pyro (python robotics) seems to require expensive (relatively)
robotic equipment.
Does anyone know anything *similar* to what I have in mind, or have
alternative suggestions ?
Regards,
Fuzzy
http://www.voidspace.org.uk/python/index.shtml
--
http://mail.python.org/mailman/listinfo/python-list

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30)

[Max M]

[EMAIL PROTECTED] wrote:
uhm ... then there is a misprint in the discussion of the recipe;
BTW what's the difference between .encode and .decode ?
(yes, I have been living in happy ASCII-land until now ... ;)

# -*- coding: latin-1 -*-
# here i make a unicode string
unicode_file = u'Some danish characters æøå' #.encode('hex')
print type(unicode_file)
print repr(unicode_file)
print ''
# I can convert this unicode string to an ordinary string.
# because æøå are in the latin-1 charmap it can be understood as
# a latin-1 string
# the æøå characters even has the same value in both
latin1_file = unicode_file.encode('latin-1')
print type(latin1_file)
print repr(latin1_file)
print latin1_file
print ''
## I can *not* convert it to ascii
#ascii_file = unicode_file.encode('ascii')
#print ''
# I can also convert it to utf-8
utf8_file = unicode_file.encode('utf-8')
print type(utf8_file)
print repr(utf8_file)
print utf8_file
print ''
#utf8_file is now an ordinary string. again it can help to think of it 
as a file
#format.
#
#I can convert this file/string back to unicode again by using the 
decode method.
#It tells python to decode this "file format" as utf-8 when it loads it 
onto a
#unicode string. And we are back where we started

unicode_file = utf8_file.decode('utf-8')
print type(unicode_file)
print repr(unicode_file)
print ''
# So basically you can encode a unicode string into a special 
string/file format
# and you can decode a string from a special string/file format back 
into unicode.

###

u'Some danish characters \xe6\xf8\xe5'

'Some danish characters \xe6\xf8\xe5'
Some danish characters æøå

'Some danish characters \xc3\xa6\xc3\xb8\xc3\xa5'
Some danish characters æøå

u'Some danish characters \xe6\xf8\xe5'


--
hilsen/regards Max M, Denmark
http://www.mxm.dk/
IT's Mad Science
--
http://mail.python.org/mailman/listinfo/python-list

Pythonic search of list of dictionaries

[Bulba!]

Hello everyone,

I'm reading the rows from a CSV file. csv.DictReader puts
those rows into dictionaries.

The actual files contain old and new translations of software
strings. The dictionary containing the row data looks like this:

o={'TermID':'4', 'English':'System Administration',
'Polish':'Zarzadzanie systemem'}

I put those dictionaries into the list:

   oldl=[x for x in orig]  # where orig=csv.DictReader(ofile ...

..and then search for matching source terms in two loops:

   for o in oldl:
   for n in newl:
   if n['English'] == o['English']:
   ...

Now, this works. However, not only this is very un-Pythonic, but also
very inefficient: the complexity is O(n**2), so it scales up very
badly.

What I want to know is if there is some elegant and efficient
way of doing this, i.e. finding all the dictionaries dx_1 ... dx_n,
contained in a list (or a dictionary) dy, where dx_i  contains
a specific value. Or possibly just the first dx_1 dictionary.

I HAVE to search for values corresponding to key 'English', since
there are big gaps in both files (i.e. there's a lot of rows 
in the old file that do not correspond to the rows in the new
file and vice versa). I don't want to do ugly things like converting
dictionary to a string so I could use string.find() method. 

Obviously it does not have to be implemented this way. If
data structures here could be designed in a proper 
(Pythonesque ;-) way, great. 

I do realize that this resembles doing some operation on 
matrixes.  But I have never tried doing smth like this in 
Python.


#-- Code follows -

import sys
import csv

class excelpoldialect(csv.Dialect):
delimiter=';'
doublequote=True
lineterminator='\r\n'
quotechar='"'
quoting=0
skipinitialspace=False

epdialect=excelpoldialect()
csv.register_dialect('excelpol',epdialect)


try:
ofile=open(sys.argv[1],'rb')
except IOError:
print "Old file %s could not be opened" % (sys.argv[1])
sys.exit(1)

try:
tfile=open(sys.argv[2],'rb')
except IOError:
print "New file %s could not be opened" % (sys.argv[2])
sys.exit(1)


titles=csv.reader(ofile, dialect='excelpol').next()
orig=csv.DictReader(ofile, titles, dialect='excelpol')
transl=csv.DictReader(tfile, titles, dialect='excelpol')

cfile=open('cmpfile.csv','wb')
titles.append('New')
titles.append('RowChanged')
cm=csv.DictWriter(cfile,titles, dialect='excelpol')
cm.writerow(dict(zip(titles,titles)))


print titles
print "-"

oldl=[x for x in orig]
newl=[x for x in transl]

all=[]

for o in oldl:
for n in newl:
if n['English'] == o['English']:
if n['Polish'] == o['Polish']:
status=''
else:
status='CHANGED'
combined={'TermID': o['TermID'], 'English': o['English'],
'Polish': o['Polish'], 'New': n['Polish'], 'RowChanged': status}
cm.writerow(combined)
all.append(combined)


# duplicates

dfile=open('dupes.csv','wb')
dupes=csv.DictWriter(dfile,titles,dialect='excelpol')
dupes.writerow(dict(zip(titles,titles)))

"""for i in xrange(0,len(all)-2):
for j in xrange(i+1, len(all)-1):
if (all[i]['English']==all[j]['English']) and
all[i]['RowChanged']=='CHANGED':
dupes.writerow(all[i])
dupes.writerow(all[j])"""
 
cfile.close()
ofile.close()
tfile.close()
dfile.close()










--

Real world is perfectly indifferent to lies that 
are the foundation of leftist "thinking".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How can engineers not understand source-code control?

[Mark Carter]

;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, first visit that file with C-x C-f,
;; then enter the text in that file's own buffer.
Cameron Laird wrote:
> Well *that* certainly made my morning unpleasant.
Then let's see if I can spoil you afternoon, too ...
I was working on a project (that used Excel, alas) that checked the 
daily allocation of oil and gas. The calculations were very complicated, 
and liable to error. I thought it would be a good idea if I serialised 
intermediate calculations so they could be checked. My solution was to 
save them as a CSV file, with array name in the first column, index 
variables in subsequent columns, and array value in the last column. 
That way, they could be checked manually. The standard approach at my 
company would have been to create honking big spreadsheets to house 
these values.

Anyway, time went on, it was decided that these daily calculations 
needed to be aggregated to monthly values. Well, it turned out that the 
solution I had adopted was quite good, because one could just suck the 
file in, read off the relevant variables, and populate an array. To be 
compared with what would normally happen of creating a nexus of links to 
a disk-busting collection of spreadsheets.

I shall have my revenge, though. The file serve hierarchy that we have 
is very complicated, and is due for simplification in the very near 
future. So all those peeps who did spreadsheets, with hard links to 
other spreadsheets, are in for a bit of a surprise. I think the I-Ching 
expressed it better than I ever could:
The bird's nest burns up.
The wanderer laughs at first,
Then must needs lament and weep.
Through carelessness he loses his cow.
Misfortune.

Source:
http://www.eclecticenergies.com/iching/hexagram.php?nr=56
I'm thinking that the I-Ching is a vast untapped resource for 
programming wisdom, plus it makes it funny. Or haikus, maybe they'd be 
good.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 30)

[Jp Calderone]

On Tue, 04 Jan 2005 16:41:05 +0100, Thomas Heller <[EMAIL PROTECTED]> wrote:
>Skip Montanaro <[EMAIL PROTECTED]> writes:
> 
> > michele> BTW what's the difference between .encode and .decode ?
> >
> > I started to answer, then got confused when I read the docstrings for
> > unicode.encode and unicode.decode:
> >
> > [snip - docstrings]
> >
> > It probably makes sense to one who knows, but for the feeble-minded like
> > myself, they seem about the same.
> 
> It seems also the error messages aren't too helpful:
> 
> >>> "ä".encode("latin-1")
> Traceback (most recent call last):
>   File "", line 1, in ?
> UnicodeDecodeError: 'ascii' codec can't decode byte 0x84 in position 0: 
> ordinal not in range(128)
> >>>
> 
> Hm, why does the 'encode' call complain about decoding?
> 
> Why do string objects have an encode method, and why do unicode objects
> have a decode method, and what does this error message want to tell me:
> 
> >>> u"ä".decode("latin-1")
> Traceback (most recent call last):
>   File "", line 1, in ?
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 
> 0: ordinal not in range(128)
> >>>

   The call

   unicode.decode(codec)

   is actually doing this

   unicode.encode(sys.getdefaultencoding()).decode(codec)

   This is not a particularly nice thing.  I'm not sure who thought
it was a good idea.  One possibility is that .encode() and .decode()
are not _only_ for converting between unicode and encoded bytestrings.
For example, there is the zlib codec, the rot13 codec, and applications
can define their own codecs with arbitrary behavior.  It's entirely 
possible to write a codec that decodes _from_ unicode objects _to_ 
unicode objects and encodes the same way.  So unicode objects need both
methods to support this use case.

  Jp
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Michael Hobbs]

Ville Vainio <[EMAIL PROTECTED]> wrote:
> What form of extreme dynamic behaviour have you been using lately?

One real-world example: in my new coverage analysis tool (to be 
released any month now), I need to trace threads without changing any
code. To do so, I redefine the thread.start_new_thread() function from
outside the thread module, like so:


orig_start_new_thread = thread.start_new_thread

def traced_start_new_thread(func, args, kwargs={}):
return orig_start_new_thread(traced_func_call, (func, args, kwargs))

def traced_func_call(func, args, kwargs):
sys.settrace(my_trace_func)
func(*args, **kwargs)

thread.start_new_thread = traced_start_new_thread


Granted, doing something like this on a regular basis is really bad
coding style, but the ability to do something like this when I really
need it is what I love about Python.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Parallelization with Python: which, where, how?

[Albert Hofkamp]

On Mon, 20 Dec 2004 14:03:09 +0100, Mathias <[EMAIL PROTECTED]> wrote:
> Can someone recommend a parallelization approach? Are there examples or 
> documentation? Has someone got experience with stability and efficiency?

If you think a light-weight approach of distributing work and collecting
the output afterwards (using ssh/rsh) fits your problem, send me an
email.

Albert
-- 
Unlike popular belief, the .doc format is not an open publically available 
format.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[Cameron Laird]

In article <[EMAIL PROTECTED]>,
Peter Dembinski  <[EMAIL PROTECTED]> wrote:
.
.
.
>def foo(x):
>return str(x)
>
>str = foo(x)
>
>And now, let's say that foo()'s definition is in another module.
>It is hard for a programmer to quickly determine the type for str,
>that's the problem with programming in languages that don't have
>type declarations.

I think I don't understand.  I believe you're saying that Python and
C might code homologously as

  def py_foo(x)
return py_bar(x)

and
  
  char *C_foo(int x)
  {
return C_bar(x);
  }

and that these definitions make it evident that C_foo() returns a
(char *), while there's no such manifest restriction on the type 
of py_foo().  Well, yes, that's so (but what did it have to do with
definitions in another module?).  There's nothing peculiar in this
to functions, right?  Python declares types of *no* bindings, so 
your claim is equally true of local variables, correct?

And this is all a *benefit* of Python, at least as I see it.  Yes,
good style in Python is different from good style in C, but the
former's strong implicit typing has, I think, equal claim to 
virtue.

Type in C are so epiphenomenal.  They communicate little of what *I*
need to know.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[Cameron Laird]

In article <[EMAIL PROTECTED]>,
Alan Gauld  <[EMAIL PROTECTED]> wrote:
>On Sat, 01 Jan 2005 16:08:07 GMT, [EMAIL PROTECTED] (Cameron
>Laird) wrote:
>
>> I argue that it's a false opposition to categorize projects in
>> terms of use of single languages.  Many projects are MUCH better
>> off with a mix 
>
>In practice I have *never* worked on an industrial scale project
>that only used one language. The nearest I came was a small
>protocol convertor that only used C, SQL and some shell and 
>awk - but that's still 4 languages! And the whole project was
>only 40,000 lines of code in about 20 files.
>
>And most projects use many more, I'd guess around 5-8 on an
>"average project" of around 300-500kloc. The biggest project I
>worked on had about 3.5Mloc and used:
>
>Assembler (680x0 and Sparc),
>C
>C++
>Lisp(Flavors)
>awk
>Bourne shell
>C shell - this was a mistake discovered too late to "fix"
>PL/SQL
> - A UI description language for a tool called TeleUse...
>Pascal - No, I don't know why...
>ASN.1 - with a commercial compiler
>
>We also had some IDL but since it was tool generated I'll ignore
>it...
>
>We also had an experimental version running on a NeXt box so it
>used Objective C for the UI instead of  and C++...
>
>A total of 13 languages... with 5 geographically dispersed teams
>comprising a total of 200 developers (plus about 40 testers).
>Interesting times...in the Chinese sense!
.
.
.
D.  The TeleUSE language http://www.aonix.com/teleuse.html > is "D".

And I suspect your count is a lower bound.  If you worked with TeleUSE, 
somebody probably was doing Motif configuration, which arguably is a(n
impoverished configuration) language itself.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Doug Holton]

Istvan Albert wrote:
But if python
were to become overly complicated I'll find something else.
Three years ago I have not not used python at all, now I'm
using it for everything.
You're in luck, python 2.4 won't be significantly changing anytime soon.
PS. why can't decorators solve this optional type checking
problem? I clearly remember this as being one of the
selling points for having decorators in the first place...
Because they are quite obviously an ugly and overly complicated 
solution.  Even Guido understood this:
http://mail.python.org/pipermail/python-dev/2004-September/048518.html

"A warning: some people have shown examples of extreme uses of
decorators. I've seen decorators proposed for argument and return type
annotations, and even one that used a decorator to create an object
that did a regular expression substitution. Those uses are cute, but I
recommend being conservative when deciding between using a decorator
or some other approach, especially in code that will see a large
audience (like 3rd party library packages). Using decorators for type
annotations in particular looks tedious, and this particular
application is so important that I expect Python 3000 will have
optional type declarations integrated into the argument list."
--
http://mail.python.org/mailman/listinfo/python-list

Cookbook 2nd ed Credits (was Re: The Industry choice)

[Alex Martelli]

<[EMAIL PROTECTED]> wrote:

> But then I have THREE published recipes!!
> Does that mean that I get three free copies of the cookbook ? ;-)

...ti piacerebbe eh...?-)  Sorry, "one each", even though you have
_five_ credits.  For the curious, here's the roster of most credited
contributors (remember, significant comments we merged into other's
recipes also count!-)...:

 1: 42 u'Alex Martelli'
 2: 26 u'Raymond Hettinger'
 3: 25 u'Luther Blissett'
 4: 22 u'Peter Cogolo'
 5: 10 u'John Nielsen'
 6: 10 u'Anna Martelli Ravenscroft'
 7:  8 u'J\x9frgen Hermann'
 8:  7 u'Scott David Daniels'
 9:  7 u'Chris Perkins'
10:  6 u'S\x8ebastien Keim'
11:  6 u'Paul Prescod'
12:  6 u'Noah Spurrier'
13:  6 u'Jeff Bauer'
14:  6 u'Holger Krekel'
15:  6 u'Danny Yoo'
16:  6 u'Brent Burley'
17:  5 u'Paul Moore'
18:  5 u'Michele Simionato'
19:  5 u'Mark Nenadov'
20:  5 u'David Eppstein'
21:  5 u'Brian Quinlan'

If you wished to count only _authored_ recipes (but that's a bit
misleading, since in several recipes-as-published there is a merge of
two or three separately submitted and accepted recipes, and here I'm
counting only the first-listed-author per published-recipe...):

 1: 25 u'Luther Blissett'
 2: 21 u'Alex Martelli'
 3:  9 u'John Nielsen'
 4:  8 u'Raymond Hettinger'
 5:  8 u'J\x9frgen Hermann'
 6:  6 u'S\x8ebastien Keim'
 7:  6 u'Peter Cogolo'
 8:  6 u'Anna Martelli Ravenscroft'
 9:  5 u'Scott David Daniels'
10:  5 u'Paul Prescod'
11:  5 u'Michele Simionato'
12:  5 u'Mark Nenadov'
13:  5 u'Jeff Bauer'
14:  5 u'Brent Burley'

...but each still gets ONE free copy...!-)


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Hlelp clean up clumpsy code

[Scott David Daniels]

Nick Coghlan wrote:
A custom generator will do nicely:
Py> def flatten(seq):
...   for x in seq:
... if hasattr(x, "__iter__"):
...   for y in flatten(x):
... yield y
... else:
...   yield x
Avoiding LBYL gives you:
def flatten(seq):
for x in seq:
try:
for y in flatten(x):
yield y
except TypeError:
yield x
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: How can engineers not understand source-code control?

[Mark Carter]

Mark Carter wrote:
I'm thinking that the I-Ching is a vast untapped resource for 
programming wisdom, plus it makes it funny. 
Well, carrying on in the same frivilous and some might say off-topic
mood, I did a bit of a Google, and found that you can generate your very
own I-Ching reading:
http://www.grillet.co.uk/iching/
According to the link at:
http://www.grillet.co.uk/iching/casting.html
"The I Ching is a good guide in taking decisions when you have no
rational basis on which to take them."  So if your project manager comes
out with something like "A pot upturned to empty the decay. The superior
one attends to the Way of Heaven.", you'll know whence he's distilling
his madness.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Using python to convert PDF document to MSWord documents

[support]

You can use "pdf to word", it can help you to batch convert pdf to word
or text at one time, keeping source layout, and Standalone software, MS
Word, Adobe Acrobat and Reader NOT required! and you can get more
information from
http://www.convertzone.com/net/cz-PDF%20to%20Word-1-1.htm.

ConvertZone Support team
ConvertZone Software Co,.ltd
http://www.convertzone.com
[EMAIL PROTECTED]


ConvertZone provides office(PDF, Word, Excel, PowerPoint, AutoCAD etc),
video(DVD, VCD, SVCD etc), audio(MP3, WAV, MIDI etc), image(JPG, GIF,
TIF, BMP etc) file converter.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Cookbook 2nd ed Credits (was Re: The Industry choice)

[Premshree Pillai]

Do contributors of less than 5 recipes get a copy too? :-?

Btw, is there a comprehensive list of ALL contributors put up anywhere?

On Tue, 4 Jan 2005 17:15:53 +0100, Alex Martelli <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote:
> 
> > But then I have THREE published recipes!!
> > Does that mean that I get three free copies of the cookbook ? ;-)
> 
> ...ti piacerebbe eh...?-)  Sorry, "one each", even though you have
> _five_ credits.  For the curious, here's the roster of most credited
> contributors (remember, significant comments we merged into other's
> recipes also count!-)...:
> 
>  1: 42 u'Alex Martelli'
>  2: 26 u'Raymond Hettinger'
>  3: 25 u'Luther Blissett'
>  4: 22 u'Peter Cogolo'
>  5: 10 u'John Nielsen'
>  6: 10 u'Anna Martelli Ravenscroft'
>  7:  8 u'J\x9frgen Hermann'
>  8:  7 u'Scott David Daniels'
>  9:  7 u'Chris Perkins'
> 10:  6 u'S\x8ebastien Keim'
> 11:  6 u'Paul Prescod'
> 12:  6 u'Noah Spurrier'
> 13:  6 u'Jeff Bauer'
> 14:  6 u'Holger Krekel'
> 15:  6 u'Danny Yoo'
> 16:  6 u'Brent Burley'
> 17:  5 u'Paul Moore'
> 18:  5 u'Michele Simionato'
> 19:  5 u'Mark Nenadov'
> 20:  5 u'David Eppstein'
> 21:  5 u'Brian Quinlan'
> 
> If you wished to count only _authored_ recipes (but that's a bit
> misleading, since in several recipes-as-published there is a merge of
> two or three separately submitted and accepted recipes, and here I'm
> counting only the first-listed-author per published-recipe...):
> 
>  1: 25 u'Luther Blissett'
>  2: 21 u'Alex Martelli'
>  3:  9 u'John Nielsen'
>  4:  8 u'Raymond Hettinger'
>  5:  8 u'J\x9frgen Hermann'
>  6:  6 u'S\x8ebastien Keim'
>  7:  6 u'Peter Cogolo'
>  8:  6 u'Anna Martelli Ravenscroft'
>  9:  5 u'Scott David Daniels'
> 10:  5 u'Paul Prescod'
> 11:  5 u'Michele Simionato'
> 12:  5 u'Mark Nenadov'
> 13:  5 u'Jeff Bauer'
> 14:  5 u'Brent Burley'
> 
> ...but each still gets ONE free copy...!-)
> 
> Alex
> --
> http://mail.python.org/mailman/listinfo/python-list
> 


-- 
Premshree Pillai
http://www.livejournal.com/~premshree
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3000 and removal of builtin callable

[Nicolas Fleury]

Mirko Zeibig wrote:
This is not an option for e.g. IDEs as some functions might actually do 
something when called ;-) and I like `callable` for introspection.

Other ways would be to check for the `__call__` attribute or use several 
methods of the `inspect`-Module, both of which are not better than 
`callable` IMHO.
I totally agree with you.  The callable function could be moved to a 
module and be built-in, but it cannot really be removed.  Calling a 
callable and know if an object is a callable without calling it is 
definitely not the same thing.

Regards,
Nicolas
--
http://mail.python.org/mailman/listinfo/python-list

Pexpect getting a defuct process

[Baillargeon, Sonny]

I am trying to use a pexpect script using python v2.3.4 with pexpect
module .999 on Solaris 8.

I try to execute this script.

#!/usr/bin/env python
'''This runs "ls -l" on a remote host using SSH.
At the prompts enter hostname, user, and password.
'''
import pexpect

logfile = open('sshls.log', 'w')

child = pexpect.spawn('ssh [EMAIL PROTECTED] ls -la')
child.setlog(logfile)
child.setmaxread(1000)
child.expect(pexpect.EOF, timeout=180)
print child.before

This used to work before but now I get a defunct process after it runs.
Any ideas?

Thanks,
Sonny



This e-mail and any attachments may contain confidential and privileged 
information. If you are not the intended recipient, please notify the sender 
immediately by return e-mail, delete this e-mail and destroy any copies. Any 
dissemination or use of this information by a person other than the intended 
recipient is unauthorized and may be illegal. Unless otherwise stated, opinions 
expressed in this e-mail are those of the author and are not endorsed by the 
author's employer.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Hlelp clean up clumpsy code

[Jp Calderone]

On Tue, 04 Jan 2005 08:18:58 -0800, Scott David Daniels <[EMAIL PROTECTED]> 
wrote:
>Nick Coghlan wrote:
> > A custom generator will do nicely:
> > 
> > Py> def flatten(seq):
> > ...   for x in seq:
> > ... if hasattr(x, "__iter__"):
> > ...   for y in flatten(x):
> > ... yield y
> > ... else:
> > ...   yield x
> 
> Avoiding LBYL gives you:
>  def flatten(seq):
>  for x in seq:
>  try:
>  for y in flatten(x):
>  yield y
>  except TypeError:
>  yield x

  But totally messes up on error handling.  Instead:

def flatten(seq):
for x in seq:
try:
subseq = iter(x)
except TypeError:
yield x
else:
for subx in flatten(subseq):
yield subx

  to avoid catching TypeErrors from .next().

  Jp
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Hans Nowak]

Alex Martelli wrote:
Iwan van der Kleyn <[EMAIL PROTECTED]> wrote:

to be determine the way foreward for Python: more features, increased
complexity, less dynamism. Lots of syntax crud, without addressing the

As a student of human nature, I'm _really_ curious as to how one could
possibly read the key document:
http://www.python.org/peps/pep-3000.html
and think in consequence of "more features, increased complexity".
Also, you keep talking about "the core python team" on the basis, it
would appear, of reading one document by Guido.  Have you bothered doing
a MINIMUM of homework, such as, looking at
http://www.amk.ca/diary/archives/cat_python.html
and specifically AMK's entry for September 30?  I'm trying to understand
whether you completely missed doing the most elementary amount of
background searching before venting on the group, or if you did find and
read the obvious documents and somehow STILL manage to completely ignore
their contents or read them as saying exactly the opposite of what they
_do_ say...
Optimistic documents about a cleaner and smaller language (and an 
improved stdlib) are all well and good, but if you look what has 
actually been happening to Python over the last few years, then the OP's 
worries don't seem so far-fetched.  "More features, increased 
complexity, less dynamism" pretty much sums it up.

Guido's posts about optional static typing seem to suggest that this 
development will continue in the same vein.  (He may just be putting his 
thoughts on paper, but it's the BDFL, so what is one supposed to think?)

I for one will NOT welcome our new static typing overlords. ;-)
--
Hans Nowak
http://zephyrfalcon.org/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Alex Martelli]

Iwan van der Kleyn <[EMAIL PROTECTED]> wrote:
   ...
> And I do sense (reading planet python/this newsgroup) a mindset or at
> least a tendency by the people who really matter in these discussion to
> keep on adding features to the syntax; to add "structure" to Python. My
> personal preference would be to leave the language alone for a while and
> to improve its infrastructure.

I happen to agree with this preference as stated here -- the time to
change the language is at 3.0 release time (say a few years from now).

It _is_, of course, perfectly sensible for Guido to start musing out
loud on the only major addition he really wants to make at that distant
time a few years from now, namely optional static typing -- it will be a
biggie when it comes, so it should not be sprung on us all by surprise;
the more (and the earlier) feedback comes to help him decide the exact
details of that addition, the merrier.

Meanwhile, over on python-dev, the discussion is on completing the
AST-branch (so the standard library may finally include a full
python-coded Python compiler when 2.5 is released, likely in 2006),
dealing (in distutils, mostly) with the fact that the Mac may use some
case-sensitive filesystems but its default one is case-preserving but
insensitive, issues with memory allocation strategies triggered by
Darwin's weird realloc behavior (a realloc there never shrinks an
allocation, eek), the best maintenance strategy for old FAQs, what
functionality is to be added to the zipfile module (e.g., removing files
from a zip archive), and the fix of a misspelling in the docs.

I kid you not: these are the threads going on today in the python-dev
list, where most of [the discussion about] Python's development really
takes place.  Not sure who you believe "really matter in these
discussion" (sic), but the discussants today included Guido van Rossum,
Tim Peters, Martin v. Loewis, and many others.  How one can possibly
infer from such raw data "a mindset or at least a tendency ... to keep
adding features to the syntax" is really hard to explain, at least for
me.  Almost invariably, the great majority of proposals to change the
language, most particularly the syntax, come on this list, fortunately,
since that leaves python-dev essentially free to keep focusing on the
huge nitty-gritty daily work of enhancing the implementation (and other
aspects of the infrastruture, such as the spelling of the docs...);
almost invariably, moreover, the great majority of such proposals come
from clueless or semi-clueless newbies or semi-newbies.

You appear to have taken the fact that Guido appears to want lot of
early discussion about his ideas on optional static typing, presumably
to help those ideas develop, and drawn from that tiny speck of 'fact'
the most absurdly extrapolated conclusions, totally and utterly ignoring
the overwhelming countervailing mass of facts and evidence that point
exactly in the opposite direction.

Of course, what YOU think should happen regarding the infrastructure,
and what the people who donate their time to actually make things happen
want, may be totally at odds.  For example, you appear to keenly want
one standard IDE to be blessed and receive all attention, one standard
web framework ditto, and so on, and so forth; most core developers, on
the other hand, appear to be very modestly inclined to spend their time
and energy in that direction, so that only a rather minor fraction of
the python-dev effort is channeled that way.  Innovative efforts are
best kept OUT of the core Python standard, many of us believe, as long
as their innovative fervor continues: once something does get into the
standard Python library &c, it won't and shouldn't develop very fast,
nor at all freely, due to the tiranny of backwards compatibility, cross
platform support, and the huge increase in maintenance/support efforts
that comes when something suddenly becomes much more widespread and
widely used than it previously used to be.  Enhancements in library
organization and functionality, fixing typos in the docs, or deciding
whether and how to work around some platform's quirks, are definitely
less glamorous than inventing new grand unification projects, but
nevertheless this kinds of things IS by far the vastest part of the work
in a large and mature open-source project.

Wonderfully innovative projects, *OUT* of the core language/library, are
very abundant.  Come to PyCon in March and you'll probably hear several
eye-opening, possibly mind-boggling talks about such things as the type
inferencing and optimizations of the pypy project, or Enthought's
breathtaking Traits and Envisage technologies -- all "infrastructure",
btw, no language changes involved.  It's perfectly fit and proper that
such work takes place exactly where it's taking place now.  If and when
it matures and stabilizes, to the point of not needing any more
innovation but rather consolidation and spreading, _then_ some part of
it may be merged into the standard c

Re: How can engineers not understand source-code control?

[Christopher Koppler]

On Tue, 04 Jan 2005 15:52:03 +, Mark Carter wrote:

> ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
> ;; If you want to create a file, first visit that file with C-x C-f,
> ;; then enter the text in that file's own buffer.

Now, _where_ have I seen that before?

> I'm thinking that the I-Ching is a vast untapped resource for 
> programming wisdom, plus it makes it funny. Or haikus, maybe they'd be 
> good.

If only all error messages were like that:

Through winter's freezing
Nature dies to live again
You need to debug

-- 
Christopher

99 bottles of Snakebite on the wall...


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonic search of list of dictionaries

[Tim Hochberg]

Bulba! wrote:
Hello everyone,
I'm reading the rows from a CSV file. csv.DictReader puts
those rows into dictionaries.
The actual files contain old and new translations of software
strings. The dictionary containing the row data looks like this:
o={'TermID':'4', 'English':'System Administration',
'Polish':'Zarzadzanie systemem'}
I put those dictionaries into the list:
   oldl=[x for x in orig]  # where orig=csv.DictReader(ofile ...
..and then search for matching source terms in two loops:
   for o in oldl:
   for n in newl:
   if n['English'] == o['English']:
   ...
Now, this works. However, not only this is very un-Pythonic, but also
very inefficient: the complexity is O(n**2), so it scales up very
badly.
What I want to know is if there is some elegant and efficient
way of doing this, i.e. finding all the dictionaries dx_1 ... dx_n,
contained in a list (or a dictionary) dy, where dx_i  contains
a specific value. Or possibly just the first dx_1 dictionary.
Sure, just do a little preprocessing. Something like (untested):

def make_map(l):
# This assumes that each English key is unique in a given l
# if it's not you'll have to use a list of o instead of o itself.
map = {}
for d in l:
if 'English' in d:
key = d['English']
map[key] = d
old_map = make_map(oldl)
new_map = make_map(newl)
for engphrase in old_map:
if engphrase in new_map:
o = old_map[engphrase]
n = new_map[engphrase]
if n['Polish'] == o['Polish']:
status=''
else:
status='CHANGED'
# process

I've assumed that the English key is unique in both the old and new 
lists. If it's not this will need some adjustment. However, your 
original algorithm is going to behave weirdly in that case anyway 
(spitting out multiple lines with the same id, but potentially different 
new terms and update status).

Hope that's useful.
-tim
I HAVE to search for values corresponding to key 'English', since
there are big gaps in both files (i.e. there's a lot of rows 
in the old file that do not correspond to the rows in the new
file and vice versa). I don't want to do ugly things like converting
dictionary to a string so I could use string.find() method. 

Obviously it does not have to be implemented this way. If
data structures here could be designed in a proper 
(Pythonesque ;-) way, great. 

I do realize that this resembles doing some operation on 
matrixes.  But I have never tried doing smth like this in 
Python.

#-- Code follows -
import sys
import csv
class excelpoldialect(csv.Dialect):
delimiter=';'
doublequote=True
lineterminator='\r\n'
quotechar='"'
quoting=0
skipinitialspace=False
epdialect=excelpoldialect()
csv.register_dialect('excelpol',epdialect)
try:
ofile=open(sys.argv[1],'rb')
except IOError:
print "Old file %s could not be opened" % (sys.argv[1])
sys.exit(1)
try:
tfile=open(sys.argv[2],'rb')
except IOError:
print "New file %s could not be opened" % (sys.argv[2])
sys.exit(1)

titles=csv.reader(ofile, dialect='excelpol').next()
orig=csv.DictReader(ofile, titles, dialect='excelpol')
transl=csv.DictReader(tfile, titles, dialect='excelpol')

cfile=open('cmpfile.csv','wb')
titles.append('New')
titles.append('RowChanged')
cm=csv.DictWriter(cfile,titles, dialect='excelpol')
cm.writerow(dict(zip(titles,titles)))
print titles
print "-"
oldl=[x for x in orig]
newl=[x for x in transl]
all=[]
for o in oldl:
for n in newl:
if n['English'] == o['English']:
if n['Polish'] == o['Polish']:
status=''
else:
status='CHANGED'
combined={'TermID': o['TermID'], 'English': o['English'],
'Polish': o['Polish'], 'New': n['Polish'], 'RowChanged': status}
cm.writerow(combined)
all.append(combined)

# duplicates

dfile=open('dupes.csv','wb')
dupes=csv.DictWriter(dfile,titles,dialect='excelpol')
dupes.writerow(dict(zip(titles,titles)))
"""for i in xrange(0,len(all)-2):
for j in xrange(i+1, len(all)-1):
if (all[i]['English']==all[j]['English']) and
all[i]['RowChanged']=='CHANGED':
dupes.writerow(all[i])
dupes.writerow(all[j])"""
 
cfile.close()
ofile.close()
tfile.close()
dfile.close()





--
Real world is perfectly indifferent to lies that 
are the foundation of leftist "thinking".
--
http://mail.python.org/mailman/listinfo/python-list

Re: Pexpect getting a defuct process

[Jorge Luiz Godoy Filho]

Baillargeon, Sonny, TerÃa 04 Janeiro 2005 14:42, wrote:

> This used to work before but now I get a defunct process after it runs.
> Any ideas?

"before" what?  What has changed in your environment to make it stop
working? 

-- 
Godoy. <[EMAIL PROTECTED]>

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Istvan Albert]

Doug Holton wrote:
application is so important that I expect Python 3000 will have
optional type declarations integrated into the argument list."
I think that *optional* part of the "optional type declaration"
is a myth.
It may be optional in the sense that the language will
accept missing declarations but as soon as the feature
is available it will become "mandatory" to use it
(peer pressure, workplace practices).
Istvan.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Carlos Ribeiro]

On Tue, 4 Jan 2005 10:39:10 -0300, Batista, Facundo
<[EMAIL PROTECTED]> wrote:
> #- need: a better standard ide, an integrated db interface with 
> #- a proper 
> #- set of db drivers (!!), a better debugger, a standard widget/windows 
> #- toolkit, something akin to a standard for web programming, better 
> #- documentation, a standard lib which is better organized, a 
> #- formalized 
> #- set of protocols and patterns for program construction. And an 
> #- interpreter which is fast enough to avoid using C or Pyrex in most 
> #- obvious cases. 
> 
> Let's take one by one: 

I'll take only a few ;-)
 
> - IDE: Better than what? Than IDLE? Than Eclipse? Than SPE? Than Pythonwin? 

I would like to seee Eric3, with some polish & opensourced on Win
(which means solving the Qt licensing problem). Perhaps someone could
convince Trolltech to release a special Qt Win version just for it
(Eric3). Eclipse is also an interesting approach.
 
> - Integrated DB interface with a proper set of db drivers (what means the
> "!!"?): What do you mean with an integrated db interface? An standard API to
> access different DB engines? Something like the Database API specification
> (http://www.python.org/topics/database/DatabaseAPI-2.0.html)? There's a SIG
> on DB at http://www.python.org/sigs/db-sig/ you may want to look at.
> Regarding drivers, to what DB do you miss one? 

At the risk of starting a huge flamewar, let's state my opinion on
this. The DBAPI itself is not a problem, despite several debates about
improvements and talks about a future version 3. On the other hand, I
wish I could simply plug & play DBAPI modules in a totally seamlessly
way. Anyone who tried know how far are we of this dream.

At the risk of sounding pessimistic, I don't see plug & play
interoperability between DBAPI drivers happening anytime soon. The
work is simply way too fragmented. There's no real incentive for
compatibility, besides the good will of individual developers, who are
always busy and also, that have to keep their own code running. The
only way it will work, IMHO, is: if a single entity implements a
common API, be it the DBAPI2.0 or whatever, for a sufficiently large
number of existing database systems. You may call it a "imposed
standard". I don't mind. But it would solve the problem.
 
> - Standard widget/windows toolkit: More standard than Tk? 

I may be wrong, but I think that most business developers expect more
than Tk is able to offer... Canvas is great, but anyone who used more
advanced toolkits (such as the ones available on Delphi, Java, or C#)
surely require a lot more.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How can engineers not understand source-code control?

[Carlos Ribeiro]

On Tue, 04 Jan 2005 15:52:03 +, Mark Carter <[EMAIL PROTECTED]> wrote:
> I'm thinking that the I-Ching is a vast untapped resource for
> programming wisdom, plus it makes it funny.

LOL! +1 QOTW!


-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Lambda as declarative idiom (was RE: what is lambda used for in real code?)

[Roman Suzi]

On Tue, 4 Jan 2005, Steven Bethard wrote:

>Roman Suzi wrote:
>> On Mon, 3 Jan 2005, Steven Bethard wrote:
>>
>>
>>>Roman Suzi wrote:
>>>
I wish lambdas will not be deprecated in Python but the key to that is
dropping the keyword (lambda). If anybody could think of a better syntax for
lambdas _with_ arguments, we could develop PEP 312 further.
>>>
>>>Some suggestions from recent lambda threads (I only considered the ones
>>>that keep lambda as an expression):
>>
>> Wow! Is there any wiki-page these could be put on?
>
>It's now on:
>
>http://www.python.org/moin/AlternateLambdaSyntax
>
>and I added Bengt Richter's and your recent suggestions.

Hmmm... what if we kill two rabbits in one blow: lambda will be even
more implicit, if we just mark parameters by a back-quote while
using PEP 312 convention:

(:f(`a) + o(`b) - o(`c))
(:`x * `x)
(:x)
(:x.bar(*`a, **`k))

Not sure about default args:

((fun(x=x, a=a, k=k): x(*a, **k)) for x, a, k in funcs_and_args_list)

Maybe this needs to be done with closures.
Otherwise I think Python interpreter is quite capable to determine
which parameters the function has... Only their order become a problem.
Probably, ","-s could be used there:

(`a,`b,`c : f(`a) + o(`b) - o(`c))

The whole expressions could be quoted:

`(x, y, z)

meaning a parameter with such structure.



>Steve
>

Sincerely yours, Roman Suzi
-- 
[EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: DB-API 2.0 in pysqlite and pgdb

[Gerhard Haering]

On Sat, Jan 01, 2005 at 06:33:24PM +0300, Roman Suzi wrote:
> 
> Happy New Year to all Pythoneers!
> 
> I am playing with pysqlite and pgdb and their DB-API conformancy.
> It was quite interesting to know:
> 
>  - sqlite doesn't have mandatory helper-functions Date, Tim, etc.
>(due to an error int it's __init__, but this is quite obvious to correct
>or just to use mx.Date, mx.Time)

Yes, that's an oversight.

> more serious mishaps with pgdb (postgresql-python):
> it doesn't know how to quote date-time data for the objects
> it has constructors itself. [...]

You may have better luck with pyPgSQL or psycopg.

-- Gerhard


signature.asc
Description: Digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Industry choice

[Bulba!]

On Mon, 3 Jan 2005 00:08:25 +0100, [EMAIL PROTECTED] (Alex Martelli)
wrote:

>> True. I have a bit of interest in economics, so I've seen e.g.
>> this example - why is it that foreign branches of companies
>> tend to cluster themselves in one city or country (e.g.

>It's not just _foreign_ companies -- regional clustering of all kinds of
>business activities is a much more widespread phenomenon.  

First, even though I disagree with you in places, thanks for 
this reply - it enhanced my knowledge of the topic in some
places.


Re the foreign/domestic companies: I have observed this what I call
"irrational clustering" esp. re foreign companies here.

>Exogenous is fine if you're looking at the decision a single firm, the
>N+1 - th to set up shop in (say) a city, faces, given decisions already
>taken by other N firms in the same sector.

>The firm's production processes have inputs and outputs, coming from
>other firms and (generally, with the exception of the last "layer" of
>retailers etc) going to other firms.  Say that the main potential buyers
>for your firm's products are firms X, Y and Z, whose locations all
>"happen to be" (that's the "exogenous" part) in the Q quarter of town.
>So, all your competitors have their locations in or near Q, too.  Where
>are you going to set up your location?   Rents are higher in Q than
>somewhere out in the boondocks -- but being in Q has obvious advantages:
>your salespeople will be very well-placed to shuttle between X, Y, Z and
>your offices, often with your designers along so they can impress the
>buyers or get their specs for competitive bidding, etc, etc.  

What you wrote regards especially strong the industries you pointed
at: fashion, jewellery, esp. I think in those industries those factors
may be decisive. When this street is renown in the city to have 
"good jewellers" located there, the choice for a new jeweller in this
city is almost like this: get located there or die.

However, I'd argue that industries with those kinds of dependencies
are actually pretty rare. 

>At some
>points, the competition for rents in quarter Q will start driving some
>experimenters elsewhere, but they may not necessarily thrive in those
>other locations.  If, whatever industry you're in, you can strongly
>benefit from working closely with customers, then quarter Q will be
>where many firms making the same products end up (supply-side
>clustering).

>Now consider a new company Z set up to compete with X, Y and Z.  Where
>will THEY set up shop?  Quarter Q has the strong advantage of offering
>many experienced suppliers nearby -- and in many industries there are
>benefits in working closely with suppliers, too (even just to easily
>have them compete hard for your business...).  

I grant that this model is neat and intuitive - but I'd argue it is
not very adequate to real world. Read on.

>So, there are easily
>appreciated exogenous models to explain demand-side clustering, too.

>That's how you end up with a Holliwood, a Silicon Valley, a Milan (for
>high-quality fashion and industrial design), even, say, on a lesser
>scale, a Valenza Po or an Arezzo for jewelry.  Ancient European cities
>offer a zillion examples, with streets and quarters named after the
>trades or professions that were most clustered there -- of course, there
>are many other auxiliary factors related to the fact that people often
>_like_ to associate with others of the same trade (according to Adam
>Smith, generally to plot some damage to the general public;-), but
>supply-side and demand-side, at least for a simpler exogenous model, are
>plenty.

>Say that it's the 18th century (after the corporations' power to stop
>"foreign" competition from nearby towns had basically waned), you're a
>hat-maker from Firenze, and for whatever reason you need to move
>yourself and your business to Bologna.  If all the best hat-makers'
>workshops and shops are clustered around Piazza dell'Orologio, where are
>YOU going to set up shop?  Rents in that piazza are high, BUT - that's
>where people who want to buy new hats will come strolling to look at the
>displays, compare prices, and generally shop.  

That will only be true if the hats from Piazza dell'Orologio are much 
better than elsewhere.

If the quality and prices of products converged, the gain for the
customers to go there isn't high. And the prices for customers
have to be higher, as the high rents drive some suppliers out,
so the supply of hats is lower, ergo customer prices are higher.

>That's close to where
>felt-makers are, since they sell to other hat-makers.  Should your
>business soon flourish, so you'll need to hire a worker, that's where
>you can soon meet all the local workers, relaxing with a glass of wine
>at the local osteria after work, and start getting acquainted with
>everybody, etc, etc...

That is true in the model. However, I don't find it very true
in practice in a lot of industries:

- "physical proximity" in this city very often means navigating

Re: The Industry choice

[Bulba!]

On Sun, 02 Jan 2005 17:18:43 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
>> This "free software" (not so much OSS) notion "but you can
>> hire programmers to fix it" doesn't really happen in practice,
>> at least not frequently: because this company/guy remains
>> ALONE with this technology, the costs are unacceptable. 
>
>Yes, but fixing python software - even sloppily written python
>software - is pretty easy. I regularly see contracts to add a feature
>to or fix a bug in some bit of OSS Python.

That's remarkable, first time I see smth like this - out of curiosity,
could you say a word where was that?


--

Real world is perfectly indifferent to lies that 
are the foundation of leftist "thinking".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python evolution: Unease

[Aahz]

In article <[EMAIL PROTECTED]>,
 <[EMAIL PROTECTED]> wrote:
>Aahz:
>>
>> The first three PSF grants were all in some way not directly related to
>> changing the core language. One was for a library, one for improving
>> Jython, and one for improving docs. Giving the PSF more money increases
>> the chances for additional work.
>
>Here is the link you forgot to post ;-)
>
>http://www.python.org/psf/grants/

Didn't forget, was lazy and short of time.

>The one about the docs seems more about teaching scientists how to use
>Python.

True, but that's still an expansion of Python's usability as opposed to
changing the core language.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing."  --Alan Perlis
-- 
http://mail.python.org/mailman/listinfo/python-list