Re: [Python-Dev] 2.4 news reaches interesting places

[Oleg Broytmann]

On Wed, Dec 08, 2004 at 08:30:02PM -0500, Phillip J. Eby wrote:
> As I explained later in that message, "native" simply means, "has an .exe 
> extension on Windows".

   And very soon that strategy will backfire - people will start PRing
"but those .exe's are nothing more than a python interpreter in
disguise" which in my opnion is even worse.

> All of the discussion about *actually* improving Python's performance is 
> moot for PR purposes.

   Hence we must stop spending our very valuable time thinking about PR
and return to actually improving Python (not only performance).

> If the goal is 
> to achieve a PR win, the important thing is to pick a meme that's capable 
> of succeeding, and stay "on message" with it.

   Translating to a plain langauge: "PSF should spend money spreading
around a counter-PR". I am afraid PSF doesn't have enough money, and
even if it has - should we really run down that path?

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4 news reaches interesting places

[Oleg Broytmann]

On Wed, Dec 08, 2004 at 10:55:59PM -0500, Raymond Hettinger wrote:
> * Have python.org prominently feature an article of Python's use in
> high-performance environments.  IIRC, somebody wrote a realtime voice
> over internet system and found that with good design, there was no speed
> issue.  Also, the cellphone apps may make a good example.

   +Games.

> * Python's website has traditionally been self-centered, leaving others
> to have to make the case for their own products.  Perhaps, it is time to
> change that.  Those who really care about speed cannot make a balanced
> decision about Python without considering psyco, pyrex, numpy, and the
> like as part of the total development environment.

   That's overreaction, I think. People always say this and that about
python - python is slow, and python is not like java, and python does
not have static type checks... And what? Should the webmasters adapt the
site to every complain?

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyOS_InputHook enhancement proposal

[Aahz]

On Thu, Dec 09, 2004, Michiel Jan Laurens de Hoon wrote:
>
> My suggestion is therefore to replace PyOS_InputHook by two functions
> PyOS_AddInputHook and PyOS_RemoveInputHook, and let Python keep track of
> which hooks are installed. This way, an extension module can add a hook
> function without having to worry about other extension modules trying
> to use the same hook.
> 
> Any comments? Would I need to submit a PEP for this proposal?

Because this is only for the C API, your best bet is to write a patch
and submit it to SF.  If people whine or it gets rejected, then write a
PEP.
-- 
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
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] How to install tile (or any other tcl module)

[Stephen Kennedy]

I've been trying to get Tile to work with python.
It can make your tkinter apps look like
http://tktable.sourceforge.net/tile/screenshots/demo-alt-unix.png
See http://tktable.sourceforge.net/tile/

Under linux I built tile from source, installed and it just works.

import Tkinter
root = Tkinter.Tk()
root.tk.call('package', 'require', 'tile')
root.tk.call('namespace', 'import', '-force', 'ttk::*')
root.tk.call('tile::setTheme', 'alt')
### Widgets are now pretty!

Under win32, I installed the binary package into python/tcl
(i.e. python/tcl/tile0.5) with all the other tcl packages, but tcl
can't find it. Any ideas?

Traceback (most recent call last):
  File "Script1.py", line 5, in ?
root.tk.call('package', 'require', 'tile')
_tkinter.TclError: can't find package tile

Stephen.

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4 news reaches interesting places

[Anthony Baxter]

On Thursday 09 December 2004 14:55, Raymond Hettinger wrote:
> * Have python.org prominently feature an article of Python's use in
> high-performance environments.  IIRC, somebody wrote a realtime voice
> over internet system and found that with good design, there was no speed
> issue.  Also, the cellphone apps may make a good example.

That was me. I gave a keynote (45 minute) version of the talk last week
at OSDC, and I believe it was videoed and will be available eventually. This
is good propaganda.

Anthony

-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Re: 2.4 news reaches interesting places

[Scott David Daniels]

Oleg Broytmann wrote:
Raymond Hettinger wrote:
* Python's website has traditionally been self-centered, leaving others
to have to make the case for their own products.  Perhaps, it is time to
change that.  Those who really care about speed cannot make a balanced
decision about Python without considering psyco, pyrex, numpy, and the
like as part of the total development environment.
   That's overreaction, I think. People always say this and that about
python - python is slow, and python is not like java, and python does
not have static type checks... And what? Should the webmasters adapt the
site to every complain?
Perhaps a link on the main page to a "for even more speed" page where we
can combine advice on how to improve application performance (measure,
abstract, choose good data structures) with references to these other
projects for particular applications.  This is the place to say things
like "operating on every character of a string is seldom efficient."
--
-- Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Re: 2.4 news reaches interesting places

[Oleg Broytmann]

On Thu, Dec 09, 2004 at 06:07:41AM -0800, Scott David Daniels wrote:
> Oleg Broytmann wrote:
> >   That's overreaction, I think.
> 
> Perhaps a link on the main page

   Why on the main page? There are Topics Guide at
http://python.org/topics/ that describes the ways Python can be used in
some popular areas. Let's add another topic, "Making things fast". Let's
even make it the first topic, though I personnaly dont see a need for
this.

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Re: 2.4 news reaches interesting places

[Anthony Baxter]

FWIW, I was planning on writing a tutorial (working title:
"Making Python Code Not Suck") for some conference
or another...  talked to a bunch of people last week at
OSDC, and it seems like something people are interested
in. Got a bunch of stuff already down from various notes
I've written in the past when helping coworkers and the like.

Anthony

-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How to install tile (or any other tcl module)

[Aahz]

On Thu, Dec 09, 2004, Stephen Kennedy wrote:
>
> I've been trying to get Tile to work with python.
> It can make your tkinter apps look like
> http://tktable.sourceforge.net/tile/screenshots/demo-alt-unix.png
> See http://tktable.sourceforge.net/tile/

Sorry, this is not a good place to get Python support; python-dev is for
people actively working on Python language development.  Please use
comp.lang.python or one of the other resources.
-- 
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
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4 news reaches interesting places

[Phillip J. Eby]

At 01:17 PM 12/9/04 +0300, Oleg Broytmann wrote:
On Wed, Dec 08, 2004 at 08:30:02PM -0500, Phillip J. Eby wrote:
> As I explained later in that message, "native" simply means, "has an .exe
> extension on Windows".
   And very soon that strategy will backfire - people will start PRing
"but those .exe's are nothing more than a python interpreter in
disguise" which in my opnion is even worse.
ISTR that for a long time, Visual Basic actually did the same thing.  A few 
magazines mentioned the fact, but nobody really cared.  However, if this is 
really a concern, bundle Pyrex as well.  Both Pyrex and py2exe are 
distutils-based, so at that point you have a complete solution, including 
the "C" meme as well as the ".exe" meme.


> If the goal is
> to achieve a PR win, the important thing is to pick a meme that's capable
> of succeeding, and stay "on message" with it.
   Translating to a plain langauge: "PSF should spend money spreading
around a counter-PR". I am afraid PSF doesn't have enough money, and
even if it has - should we really run down that path?
I'm not suggesting spending any money.  Heck, I'm not suggesting *doing* 
anything.  I just answered Guido's question about PR.  Whether anybody 
wants to *do* anything about it is an entirely separate issue from 
discussing *what* would need to be done, if something was going to be done.

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4 news reaches interesting places

[Gareth McCaughan]

On Wednesday 2004-12-08 22:39, Phillip J. Eby wrote:

[Guido:]
>> One thing that bugs me: the article says 3 or 4 times that Python is
>> slow, each time with a refutation ("but it's so flexible", "but it's
>> fast enough") but still, they sure seem to harp on the point. This is
>> a PR issue that Python needs to fight -- any ideas?

[Philip:]
> The only thing that will fix the PR issue is to have a Python compiler 
> distributed as part of the language.  It doesn't matter if it doesn't 
> support the full generality of Python, or even if it doesn't speed many 
> operations up much.  The only real requirements are that it can be used to 
> produce "native" executables, and that it be an official part of the 
> language, not a separately-distributed tool like Psyco or Pyrex.  Then, it 
> will perhaps be a sufficient "security blanket" to stop people FUDding 
> about it.

Unfortunately, this may not be enough. Consider, by way of counterexample,
Common Lisp, which
  - is compiled to native code
  - has optional type declarations
  - actually *does* run fast when compiled
  - has had all these properties for years and years
but is still almost universally decried as "slow" by people who have
never actually used it. It's true that it doesn't (as part of the
standard, and in the free implementations I know of) have the ability
to generate standalone executables with filenames ending in ".exe";
perhaps that's the key thing.

The other thing that might work is to change the name of the language
to "C" plus optional punctuation.

-- 
g

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4 news reaches interesting places

[Bill Janssen]

> The other thing that might work is to change the name of the language
> to "C" plus optional punctuation.

You mean "C@@" (pronounced C-pie-pie)?

Bill
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Re: How to install tile (or any other tcl module)

[Fredrik Lundh]

>> I've been trying to get Tile to work with python.
>> It can make your tkinter apps look like
>> http://tktable.sourceforge.net/tile/screenshots/demo-alt-unix.png
>> See http://tktable.sourceforge.net/tile/
>
> Sorry, this is not a good place to get Python support; python-dev is for
> people actively working on Python language development.  Please use
> comp.lang.python or one of the other resources.

in this case,

http://mail.python.org/mailman/listinfo/tkinter-discuss

is the right forum

(also see: http://tkinter.unpythonic.net/wiki/TkinterDiscuss )

 



___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

RE: [Python-Dev] Re: 2.4 news reaches interesting places

[Robert Brewer]

Anthony Baxter wrote:
> FWIW, I was planning on writing a tutorial (working title:
> "Making Python Code Not Suck") for some conference
> or another...

Perhaps, given your high profile in the Python developer community, you
might reconsider the title? Little details like that are what PR is made
of. Imagine Bush's next Executive Order being titled "Making American
[Business|Military|People] Not Suck"... ;)


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Re: 2.4 news reaches interesting places

[Michael Hudson]

"Robert Brewer" <[EMAIL PROTECTED]> writes:

> Anthony Baxter wrote:
>> FWIW, I was planning on writing a tutorial (working title:
>> "Making Python Code Not Suck") for some conference
>> or another...
>
> Perhaps, given your high profile in the Python developer community, you
> might reconsider the title? Little details like that are what PR is made
> of. Imagine Bush's next Executive Order being titled "Making American
> [Business|Military|People] Not Suck"... ;)

Anthony's Australian, people expect this sort of thing from him :)

Cheers,
mwh

-- 
  Also, remember to put the galaxy back when you've finished, or an
  angry mob of astronomers will come round and kneecap you with a
  small telescope for littering. 
   -- Simon Tatham, ucam.chat, from Owen Dunn's review of the year
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4 news reaches interesting places

[Phillip J. Eby]

At 04:39 PM 12/9/04 +, Gareth McCaughan wrote:
On Wednesday 2004-12-08 22:39, Phillip J. Eby wrote:
> The only thing that will fix the PR issue is to have a Python compiler
> distributed as part of the language.  It doesn't matter if it doesn't
> support the full generality of Python, or even if it doesn't speed many
> operations up much.  The only real requirements are that it can be used to
> produce "native" executables, and that it be an official part of the
> language, not a separately-distributed tool like Psyco or Pyrex.  Then, it
> will perhaps be a sufficient "security blanket" to stop people FUDding
> about it.
Unfortunately, this may not be enough. Consider, by way of counterexample,
Common Lisp, which
  - is compiled to native code
  - has optional type declarations
  - actually *does* run fast when compiled
  - has had all these properties for years and years
but is still almost universally decried as "slow" by people who have
never actually used it. It's true that it doesn't (as part of the
standard, and in the free implementations I know of) have the ability
to generate standalone executables with filenames ending in ".exe";
perhaps that's the key thing.
Among the great unwashed masses of Windows programmers, it probably 
is.  Look at the marketing for virtually any off-beat commercial language 
for Windows (that's still around to look at), and you will usually find a 
prominent bullet point about how it makes .exe's.  This is an incredibly 
powerful meme, though I don't entirely understand why.

I do agree that it still may not be enough; I'm just saying that it's not a 
coincidence that so many development tools for non-C languages on Windows 
all ended up deciding to feature that bullet point.  My theory is that it's 
because it's a FAQ, and it's often found on the official FAQ's of open 
source languages as well.

Granted, the scope of the question is much broader than just speed, since 
it also encompasses application distribution issues, and the social status 
of the developer.  One of the subtexts of the question is, "Can I make a 
*real* program with this thing?", or put more honestly, "Will other 
programmers laugh at me when they see my program isn't an .exe?"


The other thing that might work is to change the name of the language
to "C" plus optional punctuation.
Well, we could always just call it CPython, and bill it as a faster C 
implementation of that popular dynamic language for Java, Jython.  That 
way, we can also leverage the meme that C is faster than Java.  :)

Isn't it funny, by the way, that people don't go around talking about how 
slow Jython is?  At least, I haven't seen it to the extent that I've seen 
with CPython.

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4 news reaches interesting places

[James Y Knight]

On Dec 9, 2004, at 1:31 PM, Phillip J. Eby wrote:
Isn't it funny, by the way, that people don't go around talking about 
how slow Jython is?  At least, I haven't seen it to the extent that 
I've seen with CPython.
People talk about how slow CPython is, is because they are writing code 
targeted for it that traditionally would have been written in C. Python 
*is* slower than C. You can try to deny it, but it is simple fact. 
However, python is a really nice language to program in. So people use 
it anyways. It is "fast enough" for many things.

Nobody talks about how slow Jython is, because nobody(1) is writing 
entire programs in it. Jython is used as a way to script Java programs, 
and as such, it is pretty much completely unimportant how fast it runs.

Java has also traditionally got a lot of bad press for its lack of 
speed, and it was usually of the "not fast enough" variety, which is 
much worse than what's said of Python. However, a huge amount of 
progress has been made and Java really is quite speedy these days. It 
was not PR that made it faster, but hard work on the part of Sun.

There is currently a lot of work going on in the python community to 
make Python faster, which indicates both that Python is too slow for 
some people, and that it will be faster in the future. This is a good 
thing, and not something that should be shoved under the rug to try to 
pretend python is ultra mega super fast already.

James
1) Of course someone probably is, but you get the idea.
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

RE: [Python-Dev] Re: 2.4 news reaches interesting places

[Delaney, Timothy C (Timothy)]

Michael Hudson wrote:

> Anthony's Australian, people expect this sort of thing from him :)

As another Australian, I think that "Making Python Not Suck" implies
that if you don't do extra things, Python Sucks.

This is not a good thing IMO.

"Making Python Suck Less" would be even worse.

How about "Python - You Can Have Your Cake And Eat It Too".

Tim Delaney
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4 news reaches interesting places

[Jeremy Hylton]

On Thu, 9 Dec 2004 14:16:18 -0500, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Dec 9, 2004, at 1:31 PM, Phillip J. Eby wrote:
> > Isn't it funny, by the way, that people don't go around talking about
> > how slow Jython is?  At least, I haven't seen it to the extent that
> > I've seen with CPython.
> 
> People talk about how slow CPython is, is because they are writing code
> targeted for it that traditionally would have been written in C. Python
> *is* slower than C. You can try to deny it, but it is simple fact.
> However, python is a really nice language to program in. So people use
> it anyways. It is "fast enough" for many things.

I think you are exactly right.  It's easy to get the impression that
Python is slow when many programs written in Python *are* slowly than
the same program written in C, C++, or Java.  If you look are other
"dynamic" languages, you'll find that IronPython is often faster than
CPython and that Smalltalk and Common Lisp are often substantially
faster than Python.  Python isn't remarkably slow for a scripting
language, but it is not fast.

> There is currently a lot of work going on in the python community to
> make Python faster, which indicates both that Python is too slow for
> some people, and that it will be faster in the future. This is a good
> thing, and not something that should be shoved under the rug to try to
> pretend python is ultra mega super fast already.

I agree, although it's not clear to me how much faster it will be in
the future.  Making a *fast* Python based on our own virtual execution
environment (as opposed to piggybacking a JVM or CLR) is a big
project.  It's not clear than anyone has enough resources to make
credible effort, so we're left to piecemeal improvements.  The
improvement I see from 2.2 to 2.4 on my box is about 55% (measured
using pystone) over almost three years.

I think the right thing to do with PR is frame the question
differently.  We need to say that people use Python because it lets
them right clear, simple code or that it is easy to maintain or that
dynamic languages are excellent for prototyping -- whatever the
message is -- and simply avoid talking about speed.  There are a lot
of issues that affect the selection of a programming language, and
speed is not always the most important one.  It is easy for a
journalist to write about and it is easy to report (possibly
meaningless) measurements of speed.

Jeremy
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Re: 2.4 news reaches interesting places

[Simon Percivall]

On 2004-12-09, at 15.07, Scott David Daniels wrote:
Oleg Broytmann wrote:
Raymond Hettinger wrote:
* Python's website has traditionally been self-centered, leaving 
others
to have to make the case for their own products.  Perhaps, it is 
time to
change that.  Those who really care about speed cannot make a 
balanced
decision about Python without considering psyco, pyrex, numpy, and 
the
like as part of the total development environment.
   That's overreaction, I think. People always say this and that about
python - python is slow, and python is not like java, and python does
not have static type checks... And what? Should the webmasters adapt 
the
site to every complain?
Perhaps a link on the main page to a "for even more speed" page where 
we
can combine advice on how to improve application performance (measure,
abstract, choose good data structures) with references to these other
projects for particular applications.  This is the place to say things
like "operating on every character of a string is seldom efficient."
+1
Many examples of common idioms and tasks and how to do them right in 
Python
would also be useful for such a page.

//Simon
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

RE: [Python-Dev] Re: 2.4 news reaches interesting places

[Dennis Allison]

The goal here is to make Python better known and to counter some of the
prevalent myths.  One way to accomplish this goal is to publish literate
technical articles with real content including performance measurements
and pointers to the code.  Perhaps Guido could be a real-life N. Bourbaki
and co-publish with developers.

A significant issue is: where to publish.  Certainly publishing in the
technical society journals (ACM & IEEE CS) would make sense.  Software
Practice and Experience would also be good.  Likewise DDJ and Game
Developer Magazine. But I suspect that much of our target audience will be
missed if we limit ourselves to these journals.  We also need to get
articles placed in the mass market computer mags.  And we need to build an
editorial relationship with the mass market journals so that when X says 
they think "Python is slow" there's some they know they can call for a
truth-squad quote.

And, parenthetically, I continue to be amazed at the number of projects
that use Python, but do it in stealth-mode and view it as their
silver-bullet and competative edge.  I wish more people would publish
their experience.





___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4 news reaches interesting places

[Glyph Lefkowitz]

On Wed, 2004-12-08 at 17:39 -0500, Phillip J. Eby wrote:

> The only thing that will fix the PR issue is to have a Python compiler 
> distributed as part of the language.  It doesn't matter if it doesn't 
> support the full generality of Python, or even if it doesn't speed many 
> operations up much.  The only real requirements are that it can be used to 
> produce "native" executables, and that it be an official part of the 
> language, not a separately-distributed tool like Psyco or Pyrex.  Then, it 
> will perhaps be a sufficient "security blanket" to stop people FUDding 
> about it.

I am aware that Pyrex is still in flux, so perhaps it is too soon to
propose this even for 2.5, but I think it's worth bringing up anyway: I
would like Pyrex to be distributed with the Python core.  I agree that
it should be modified to produce full .exe files and not just .dlls on
Windows, but many potential users *are* seriously concerned about
efficiency and not just simplifying distribution.

The main benefit would be imparting a Pythonesque flavor to optimized
code.  The thing which experienced Python-ers say is, technically,
correct: "If you need speed, rewrite the hot-spots in C.".  To someone
already steeped in the Python way, this means, "write your application
in Python, do your architecture in Python, profile it, and write the 300
lines or so of your 25000 line application that are *really*
speed-critical in a faster language".  There are a few, very very
specialized areas where this approach is not the best one, but
unfortunately C programmers do not hear this when you say it.

What they hear is, "If speed is important to your application, write it
in C, and only write the parts where you need flexibility in Python.
They will all be deadly slow.  If you notice that they are slow, you are
going to have to rewrite them in C anyway."  To wit, Python is only
interesting to the people who are going to "script" your application.

Although writing code in Pyrex ends up being a technically similar
solution, politically it is radically different.  If the Python-expert's
answer were instead, "write the slow parts in Pyrex", then the C
programmer's plan changes - instead of writing in C, because they know
they are going to need to rewrite all the slow parts anyway, they
realize that there is an explicitly Python way to rewrite the slow
parts, that may leverage SOME of their existing C knowledge.  They learn
Python and appreciate Python secure in the knowledge that this effort
will not be wasted.

Finally, there are real benefits to Pyrex when making the transition
between levels in your optimized code.  All the common areas for
mistakes when interfacing with Python - missing refcounts when getting,
changing, or deleting attributes, calling Python callbacks, and using
basic Python data structures - are all taken care of so that the dive
into C is far less abrupt.  The people this PR is geared to are those
who would write in C because of efficiency concerns, so they would
likely be looking at Pyrex before choosing to start a large project, and
the simple code examples would be both familiar enough (hey, that's a 32
bit integer!  I remember that!) but also different enough (wow, you can
just call a script with "foo()"?) that they would be impressed.


___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Freezing Python (was Re: [Python-Dev] 2.4 news reaches interesting places)

[Barry Warsaw]

On Thu, 2004-12-09 at 10:30, Phillip J. Eby wrote:

> ISTR that for a long time, Visual Basic actually did the same thing.  A few 
> magazines mentioned the fact, but nobody really cared.  However, if this is 
> really a concern, bundle Pyrex as well.  Both Pyrex and py2exe are 
> distutils-based, so at that point you have a complete solution, including 
> the "C" meme as well as the ".exe" meme.

As an aside, I wonder if there's interest in collaborating on freeze
tools among the various existing solutions here.  I've recently needed
to look at this and I chose cx_Freeze, primarily because it supported
the platforms I needed.  It's a very good tool.

I've had some conversations with Anthony Tuininga on the cx_Freeze
mailing list and there seems to be some interest in perhaps putting
together a SIG or something.

-Barry



signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: Freezing Python (was Re: [Python-Dev] 2.4 news reaches interesting places)

[Bob Ippolito]

On Dec 9, 2004, at 4:20 PM, Barry Warsaw wrote:
On Thu, 2004-12-09 at 10:30, Phillip J. Eby wrote:
ISTR that for a long time, Visual Basic actually did the same thing.  
A few
magazines mentioned the fact, but nobody really cared.  However, if 
this is
really a concern, bundle Pyrex as well.  Both Pyrex and py2exe are
distutils-based, so at that point you have a complete solution, 
including
the "C" meme as well as the ".exe" meme.
As an aside, I wonder if there's interest in collaborating on freeze
tools among the various existing solutions here.  I've recently needed
to look at this and I chose cx_Freeze, primarily because it supported
the platforms I needed.  It's a very good tool.
I've had some conversations with Anthony Tuininga on the cx_Freeze
mailing list and there seems to be some interest in perhaps putting
together a SIG or something.
That's certainly worth doing.  Currently we have, in general use, at 
least cx_Freeze, py2exe, and py2app.

I have been abstracting away a lot of the dependency finding issues in 
py2app into a cross-platform module called modulegraph 
.  
Modulegraph supercedes the standard library modulefinder.  Because it 
uses a graph data structure, it gives you the flexibility say "pydoc 
doesn't *really* depend on Tkinter".  It also has functionality that 
lets you specify implicit dependencies (via PyImport_.. or such), so 
that it plays nicely enough with C extensions.

This code is basically at the point where py2exe and cx_Freeze could 
import it and use it instead of modulefinder (with a small amount of 
hacking, the API is different).

-bob
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Re: 2.4 news reaches interesting places

[Aahz]

On Thu, Dec 09, 2004, Dennis Allison wrote:
>
> And, parenthetically, I continue to be amazed at the number of projects
> that use Python, but do it in stealth-mode and view it as their
> silver-bullet and competative edge.  I wish more people would publish
> their experience.

http://www.paulgraham.com/avg.html
-- 
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
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4 news reaches interesting places

[Phillip J. Eby]

At 04:11 PM 12/9/04 -0500, Glyph Lefkowitz wrote:
On Wed, 2004-12-08 at 17:39 -0500, Phillip J. Eby wrote:
> The only thing that will fix the PR issue is to have a Python compiler
> distributed as part of the language.  It doesn't matter if it doesn't
> support the full generality of Python, or even if it doesn't speed many
> operations up much.  The only real requirements are that it can be used to
> produce "native" executables, and that it be an official part of the
> language, not a separately-distributed tool like Psyco or Pyrex.  Then, it
> will perhaps be a sufficient "security blanket" to stop people FUDding
> about it.
I am aware that Pyrex is still in flux, so perhaps it is too soon to
propose this even for 2.5, but I think it's worth bringing up anyway: I
would like Pyrex to be distributed with the Python core.  I agree that
it should be modified to produce full .exe files and not just .dlls on
Windows, but many potential users *are* seriously concerned about
efficiency and not just simplifying distribution.
+1 on all the stuff you said, with one minor exception.  Pyrex-the-language 
is often unpythonically ugly and verbose at present.  If Python had an 
official syntax for optional static type declaration, Pyrex's syntax could 
be aligned with that, and that would at least eliminate most of the inline 
'cdef' ugliness, leaving only C type declarations and Python property 
declarations as the main syntax issues to be resolved.  (Maybe by using 
something like the 'ctypes' API, and having the compiler recognize that 
API, such that C is directly callable from Python anyway, so compiling or 
interpreting Python makes no difference to ability to access C...  but I 
digress.)

Of course, this would take some effort from the core developers, especially 
Guido, to consider the various syntax needs and formulate official 
solutions.  But if it were done, the Python-vs.-Pyrex distinction could 
fade away altogether, replaced with the meme, "just add type declarations 
to slow parts, and tell Python you want the module compiled to C."

IOW, if Pyrex is merely the name of a compiler, not a separate language, 
then our master plan for world domination is complete.  :)

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4 news reaches interesting places

[Michael Walter]

If I parse you correctly, this would be great.

- Michael


On Thu, 09 Dec 2004 16:37:59 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> At 04:11 PM 12/9/04 -0500, Glyph Lefkowitz wrote:
> 
> 
> >On Wed, 2004-12-08 at 17:39 -0500, Phillip J. Eby wrote:
> >
> > > The only thing that will fix the PR issue is to have a Python compiler
> > > distributed as part of the language.  It doesn't matter if it doesn't
> > > support the full generality of Python, or even if it doesn't speed many
> > > operations up much.  The only real requirements are that it can be used to
> > > produce "native" executables, and that it be an official part of the
> > > language, not a separately-distributed tool like Psyco or Pyrex.  Then, it
> > > will perhaps be a sufficient "security blanket" to stop people FUDding
> > > about it.
> >
> >I am aware that Pyrex is still in flux, so perhaps it is too soon to
> >propose this even for 2.5, but I think it's worth bringing up anyway: I
> >would like Pyrex to be distributed with the Python core.  I agree that
> >it should be modified to produce full .exe files and not just .dlls on
> >Windows, but many potential users *are* seriously concerned about
> >efficiency and not just simplifying distribution.
> 
> +1 on all the stuff you said, with one minor exception.  Pyrex-the-language
> is often unpythonically ugly and verbose at present.  If Python had an
> official syntax for optional static type declaration, Pyrex's syntax could
> be aligned with that, and that would at least eliminate most of the inline
> 'cdef' ugliness, leaving only C type declarations and Python property
> declarations as the main syntax issues to be resolved.  (Maybe by using
> something like the 'ctypes' API, and having the compiler recognize that
> API, such that C is directly callable from Python anyway, so compiling or
> interpreting Python makes no difference to ability to access C...  but I
> digress.)
> 
> Of course, this would take some effort from the core developers, especially
> Guido, to consider the various syntax needs and formulate official
> solutions.  But if it were done, the Python-vs.-Pyrex distinction could
> fade away altogether, replaced with the meme, "just add type declarations
> to slow parts, and tell Python you want the module compiled to C."
> 
> IOW, if Pyrex is merely the name of a compiler, not a separate language,
> then our master plan for world domination is complete.  :)
> 
> 
> 
> ___
> Python-Dev mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com
>
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4 news reaches interesting places

[Glyph Lefkowitz]

On Thu, 2004-12-09 at 16:37 -0500, Phillip J. Eby wrote:

> +1 on all the stuff you said, with one minor exception.  Pyrex-the-language 
> is often unpythonically ugly and verbose at present.

Personally I have no problem with Pyrex's current tradeoffs, but given
the amount of effort that this is going to inevitably involve, I'm sure
that at least some of the changes you suggested would be necessary.
So... +0 on your suggestions, I suppose.


___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.4 news reaches interesting places

[Martijn Faassen]

Guido van Rossum wrote:
[snip]
One thing that bugs me: the article says 3 or 4 times that Python is
slow, each time with a refutation ("but it's so flexible", "but it's
fast enough") but still, they sure seem to harp on the point. This is
a PR issue that Python needs to fight -- any ideas?
One thing you could do is announce loudly that the European Union is 
actually funding a international consortium of scientists, industry and 
software engineers to speed up Python (among other things :) -- PyPy.

I'm sure that a press release about this in the right channels could 
make quite a bit of positive noise. "Python, backed by the EU". Of 
course one worry is that the 'slow bureaucracy' meme would rub off on it.

Of course any press release would need to be discussed with the PyPy people.
Regards,
Martijn
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Proposed Mac OS X change for 2.3.5 and 2.4.1 - MACOSX_DEPLOYMENT_TARGET vs. Python, round two, fight!

[Bob Ippolito]

I've included a lot of background information here, if you just want to 
know the details
of the proposed change, skip to the bottom.

As some of you may know, Python 2.4's configure script and distutils 
has some
tricky behavior with regard to the ``MACOSX_DEPLOYMENT_TARGET`` 
environment
variable on Mac OS X 10.3 and later.  Unless otherwise specified, 
assume that I
am talking about a build environment of Mac OS X 10.3 or later.  This 
behavior
is as follows:

If ``MACOSX_DEPLOYMENT_TARGET`` is not set during configure:
1.  distutils builds modules with
``-F/Python/Installation/Location -framework Python`` as per usual 
2.3.x
behavior if it is also not set
2.  If ``MACOSX_DEPLOYMENT_TARGET`` is set during a later run of 
distutils, then
distutils complains that "10.3" mismatches the configure time 
setting of ""

This Python framework has the following misfeatures:
1.  All your extensions are dependent on the installation location of 
this
particular Python
2.  This installation of Python 2.4 *may break the building of 
extensions* for
any previous version of Python that uses the same distutils 
behavior.  It
will certainly break them if they are installed to the same 
framework
directory, but if the version of Python 2.3 is early enough, such 
as the
stock 2.3.0, it will break that too.  Also, any future version of 
Python
installed to the same frameworks directory *will break the building 
of
extensions* for this Python installation!
3.  The Python framework will not be compatible with versions of Mac OS 
X
earlier than 10.3 anyway due to changes in libSystem!

This is stupid, and it should NOT be default behavior!
If ``MACOSX_DEPLOYMENT_TARGET`` is set to "10.3" or higher during 
configure:

1.  distutils builds modules with ``-undefined dynamic_lookup``
2.  If ``MACOSX_DEPLOYMENT_TARGET`` is set to something other than 
"10.3", or
unset, it will complain that the current setting mismatches the 
configure
setting of "10.3"

The features:
1.  All your extensions are independent of the Python installation 
location,
and are thus compatible with any other Python with the same major 
version.
2.  This installation of Python 2.4 will still, unavoidably, break the 
building
of extensions for any previous version of Python using the bad 
distutils
behavior mentioned above.  This installation is not susceptible to
breakage, however.

The misfeatures:
1.  You need to have ``MACOSX_DEPLOYMENT_TARGET`` set during configure, 
most
people don't know to do this.
2.  You also need to have ``MACOSX_DEPLOYMENT_TARGET`` set when using
distutils.  Even less people know to do this.

The solution to this is to have the following behavior instead:
1.  If no ``MACOSX_DEPLOYMENT_TARGET`` is set during configure, and the 
build
machine is Mac OS X 10.3 or later, then set it to "10.3".
2.  If no ``MACOSX_DEPLOYMENT_TARGET`` is set during distutils, but it 
WAS
set during configure, then set it to the configure time value.
3.  Otherwise, if it is set to a LOWER value, then fail.  Checking for 
an
exact match is bad, because the user or extension author should be
free to build a particular extension using 10.4 specific features
against a Python that is 10.3+ compatible.

For a build machine running Mac OS X 10.2 or earlier, it should ignore
all of this behavior as per usual.
Unless anyone has a reasonable objection to this proposed solution, then
we should make sure it goes into Python 2.4.1 and Python 2.3.5.
These threads might also be of interest:
http://mail.python.org/pipermail/pythonmac-sig/2004-November/012192.html
http://mail.python.org/pipermail/pythonmac-sig/2004-December/012237.html
http://mail.python.org/pipermail/pythonmac-sig/2004-December/012275.html
-bob
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

RE: [Python-Dev] 2.4 news reaches interesting places

[Skip Montanaro]

Raymond> * Any PR effort should also emphasize that no usability
Raymond>   trade-offs were made along the way.  A number of features
Raymond>   make Py2.4 easier to use than 1.5.6: list comps, genexps,
Raymond>   generators, sets, nested scopes, int/long unification,
Raymond>   decorators, etc. 

Not to mention which, such beasts aren't commonly available for C.  What
about C++?

I found it interesting that a guy at work wrote a string caching class for
our C++ programmers to use.  He told me he got the idea from Python's int
caching.

Skip
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Re: 2.4 news reaches interesting places

[Anthony Baxter]

On Friday 10 December 2004 06:25, Delaney, Timothy C (Timothy) wrote:
> Michael Hudson wrote:
> > Anthony's Australian, people expect this sort of thing from him :)
>
> As another Australian, I think that "Making Python Not Suck" implies
> that if you don't do extra things, Python Sucks.
>
> This is not a good thing IMO.
>
> "Making Python Suck Less" would be even worse.

Don't worry - it will have a nice friendly title by the time I present it.
I'm currently aiming for OSCON, which isn't until August. It's going
to be aimed at people who _know_ Python, but aren't necessarily 
experts, and focus not just on performance, but maintainable and 
sane code (for instance, not many people seem to realise that 
__del__ methods are almost always not the right answer to a problem).

> How about "Python - You Can Have Your Cake And Eat It Too".

Nah - I have a bunch of ideas kicking around in my head, something
will pop out. I doubt I'll ever be able to top the title of my pycon talk,
though... 

Anthony
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyOS_InputHook enhancement proposal

[Keith Dart]

Aahz wrote:
On Thu, Dec 09, 2004, Michiel Jan Laurens de Hoon wrote:
My suggestion is therefore to replace PyOS_InputHook by two functions
PyOS_AddInputHook and PyOS_RemoveInputHook, and let Python keep track of
which hooks are installed. This way, an extension module can add a hook
function without having to worry about other extension modules trying
to use the same hook.
Any comments? Would I need to submit a PEP for this proposal?

Because this is only for the C API, your best bet is to write a patch
and submit it to SF.  If people whine or it gets rejected, then write a
PEP.
I did modify the readline module that hooks this and can call back to a 
Python function. There are also methods for installing and removing the 
Python function. I did this for a different reason. I need Python signal 
handlers to run, and they don't run when the execution path is currently 
in some C code (such as readline). The hook forces the interpreter to 
run, and check for signals as a side effect. Using this I can be sitting 
in raw_input(), or interactive mode, and signal handlers are still run.

If you want it, let me know.
Actually, the modded readline module is part of pyNMS, on sourceforge.

--
   \/ \/
   (O O)
-- oOOo~(_)~oOOo
Keith Dart <[EMAIL PROTECTED]>
vcard: 
public key: ID: F3D288E4   URL: 

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com