Re: [Python-Dev] [pypy-dev] Python Software Foundation seeks mentors and students for Google Summer of Code

[Simon Wittber]

On 4/20/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> This spring and summer, Google will again provide stipends
> for students (18+, undergraduate thru PhD programs) to write
> new open-source code.



> People interested in mentoring a student though PSF are encouraged to
> contact me, Neal Norwitz at [EMAIL PROTECTED]  People unknown to Guido
> or myself should find a couple of people known within the Python community
> who are willing to act as references.

I (and my employer, Digital Ventures) are prepared to allocate a small
amount of time to mentor students who are working on any game or
multimedia related projects. As a company, this is a new area of
business development which we are investigating, and we are therefore
very keen to see Python develop further along these lines.



-Simon Wittber
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python 2.5alpha and naming schemes

[Thomas Heller]

Martin v. Löwis wrote:
> Dennis Heuer wrote:
>> Module names
>> like hashlib are not python-like too (too c/lowlevel-like).
> 
> I agree with Greg: hashlib is a Pythonic name for a module,
> just like httplib, mhlib, xmlrpclib, cookielib, contextlib,
> difflib, ...
> 
> OTOH, it might be indeed that the ctypes name need to be
> aligned with naming conventions.
> 

Personally, I *like* the ctypes name.  But I'm open for suggestions,
and it might have intersting consequences if the Python core package
would be renamed to something else.

Any suggestions?

Thomas

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

[Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Mateusz Rukowicz]

I wish to participate in Google Summer of Code as a python developer. I
have few ideas, what would be improved and added to python. Since these
changes and add-ons would be codded in C, and added to python-core
and/or as modules,I am not sure, if you are willing to agree with these
ideas.

First of all, I think, it would be good idea to speed up long int
implementation in python. Especially multiplying and converting
radix-2^k to radix-10^l. It might be done, using much faster algorithms
than already used, and transparently improve efficiency of multiplying
and printing/reading big integers.

Next thing I would add is multi precision floating point type to the
core and fraction type, which in some cases highly improves operations,
which would have to be done using floating point instead.
Of course, math module will need update to support multi precision
floating points, and with that, one could compute asin or any other
function provided with math with precision limited by memory and time.
It would be also good idea to add function which computes pi and exp
with unlimited precision.
And last thing - It would be nice to add some number-theory functions to
math module (or new one), like prime-tests, factorizations etc.

Every of above improvements would be coded in pure C, and without using
external libraries, so portability of python won't be cracked, and no
new dependencies will be added.

I am waiting for your responses about my ideas, which of these you think
are good, which poor etc. Main reason I am posting my question here is
that, I am not sure, how much are you willing to change the core of the
python.

At the end, let my apologize for my poor English, I am trying to do my best.

Best regards,
Mateusz Rukowicz.


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

Re: [Python-Dev] Raising objections

[Michael Hudson]

"A.M. Kuchling" <[EMAIL PROTECTED]> writes:

> On Thu, Apr 20, 2006 at 07:53:55AM +0200, "Martin v. Löwis" quoted:
>> > It is flatly not possible to "fix" distutils and preserve backwards 
>> > compatibility.
>
> Would it be possible to figure what parts are problematic, and
> introduce PendingDeprecationWarnings or DeprecationWarnings so 
> that we can fix things?

Broadly speaking, no.

Cheers,
mwh
(I've looked into the distutils source too, and have the claw marks on
my soul to prove it)


-- 
  I'm sorry, was my bias showing again? :-)
  -- William Tanksley, 13 May 2000
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] bin codec + EOF

[tomer filiba]

yeah, i came to realize nothing helpful will ever come out from this list, so i might as well stop trying. but i have one last thing to try.i'm really missing a binary codec, just like the hex codec, for doing things like
>>> "abc".encode("bin")"01110110001001100011">>> "01110110001001100011".decode("bin")"abc"
decode should also support padding, either None, "left", or "right", i.e.,>>> "1".decode("bin") # error>>> "1".decode("bin", "left) # 0001
'\x01'
>>> '1'.decode("bin", "right") # 1000
'\x80'

i've written a codec by myself for that, it's not that complicated, but the problemis, because it's not in the standard encodings package, i can't distribute code thatuses it easily:* i have to distribute it with every release, or i'll enter a dependency nightmare.
* i'd have to provide setup instructions for the codec ("put this file in ../encodings")and rely on user's abilities. it's not that i think my users are incapable of doing so,but my distro shouldn't rely on my users.
* upgrading more complicated (need to fix several locations)* i don't want to write intrusive setups. i like to keep my releases as simple as zip files that the user just needs to extract to /site-packages, with no configuration or 
setup hassle. setups are too dangerous imho, you can't tell they if they'd mess upyour configuration.so i resorted to an encode_bin and decode_bin functions that are included with my code. of course this codec should be written in c to make it faster, as it's quite a
bottleneck in my code currently.it's a trivial and useful codec that should be included in the stdlib. saying "you canwrite it for yourself" is true, but the same came be said about "hex", which can 
even be written as a one-liner: "".join("%02x" % (ord(ch),) for ch in "abc")so now that it's said, feel free to (-1) it by the millions. don't worry, i will not waste my or your time anymore. 
-tomer
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils thoughts

[Greg Ewing]

While we're on the subject of distutils revision, here
are a few things I've encountered about distutils which
seem less than desirable.

* There doesn't seem to be a way of supplying options
   on the command line for anything except the top-level
   command. Sometimes, e.g. I want to do an "install" but
   override some options for the "build_ext" that gets
   invoked by the install. But distutils won't let me,
   because those options are not recognised by the
   "install" command itself.

   If I try to get around this by doing a "build_ext"
   explicitly, then "install", the build_ext gets done
   again the second time around, without my options.

   I know I can do this using a config file, but the
   details of that don't seem to fit in my brain, and
   I have to go looking up the docs. Come to that,
   almost none of distutils seems to fit in my brain.
   Whenever I go to write a new setup.py I have to
   go and read the docs to remind myself what it's
   supposed to look like.

* It seems to be next to impossible to override some
   of the options that get passed to the C compiler.
   For Pyrex I'd very much like to be able to turn off
   the -Wall that it seems to insist on using, but I
   haven't been able to find a way. Last time I tried,
   I got lost in a maze of twisty method calls, all
   alike.

* The mechanisms for extending it seem clumsy. Since
   there's an Extension class, the you'd think the
   obvious way to add support for Pyrex would be to
   define a PyrexExtension type that embodied all the
   necessary knowledge to deal with a .pyx file. But
   that's not the way it seems to work. The current
   Pyrex distutils extension (which I didn't write)
   works by hijacking a pre-existing method designed
   for processing swig files. If that's really the
   cleanest way it can be done, something is badly
   wrong with the design.

   This is what I meant when I said I'd like a more
   Scons-like approach. Someone complained that Scons
   was too magical. I don't necessarily want it to
   behave exactly like Scons, but just to have the
   functionality divided into independent parts that
   can be composed in the manner of Scons, so that I
   could add a component for processing .pyx -> .c
   that builds on the existing components for dealing
   with .c files, and do it in an obvious and straight-
   forward way (and hopefully without having to be
   excessively Dutch in order to see the obviousness
   of it:-).

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] proposal: evaluated string

[Greg Ewing]

tomer filiba wrote:

> first of all -- i know there's a bunch of templating engines, but i 
> think it should be a built-in feature of the language.

One fairly serious drawback to this idea is that it
inhibits i18n. For security reasons it has to be
implemented at compile time and only work on string
literals. But then you can't use an i18n package to
rewrite the string at run time. And trying to i18n
the component parts of the string doesn't work
because of grammatical differences between languages.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

[Greg Ewing]

Martin v. Löwis wrote:

> Some libraries (not necessarily in Python) have gone the path of
> providing a "unified" API for all kinds of file stream access,
> e.g. in KDE, any tool can open files over many protocols, without
> the storage being mounted locally.

Maybe a compromise would be to provide an extended
version of open() that knew about zip files. This
could be a stand-alone facility to complement zip
importing, and needn't be tied to distutils or
setuptools or anything like that. Code which finds
things using module __file__ attributes would work
exactly the way it does now as long as it used the
special open().

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [pypy-dev] Python Software Foundation seeks mentors and students for Google Summer of Code

[Guido van Rossum]

To all who are volunteering like this: great -- but please add your
idea to the wiki and sign up through the Google SoC website!
(code.google.com/soc/)

--Guido

On 4/21/06, Simon Wittber <[EMAIL PROTECTED]> wrote:
> On 4/20/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > This spring and summer, Google will again provide stipends
> > for students (18+, undergraduate thru PhD programs) to write
> > new open-source code.
>
> 
>
> > People interested in mentoring a student though PSF are encouraged to
> > contact me, Neal Norwitz at [EMAIL PROTECTED]  People unknown to Guido
> > or myself should find a couple of people known within the Python community
> > who are willing to act as references.
>
> I (and my employer, Digital Ventures) are prepared to allocate a small
> amount of time to mentor students who are working on any game or
> multimedia related projects. As a company, this is a new area of
> business development which we are investigating, and we are therefore
> very keen to see Python develop further along these lines.
>
>
>
> -Simon Wittber
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python 2.5alpha and naming schemes

[Guido van Rossum]

I suggest to ignore this thread. The OP seems clueless and the names
are fine. Don't waste your time.

On 4/21/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > Dennis Heuer wrote:
> >> Module names
> >> like hashlib are not python-like too (too c/lowlevel-like).
> >
> > I agree with Greg: hashlib is a Pythonic name for a module,
> > just like httplib, mhlib, xmlrpclib, cookielib, contextlib,
> > difflib, ...
> >
> > OTOH, it might be indeed that the ctypes name need to be
> > aligned with naming conventions.
> >
>
> Personally, I *like* the ctypes name.  But I'm open for suggestions,
> and it might have intersting consequences if the Python core package
> would be renamed to something else.
>
> Any suggestions?
>
> Thomas
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Guido van Rossum]

On 4/21/06, Mateusz Rukowicz <[EMAIL PROTECTED]> wrote:
> I wish to participate in Google Summer of Code as a python developer. I
> have few ideas, what would be improved and added to python. Since these
> changes and add-ons would be codded in C, and added to python-core
> and/or as modules,I am not sure, if you are willing to agree with these
> ideas.
>
> First of all, I think, it would be good idea to speed up long int
> implementation in python. Especially multiplying and converting
> radix-2^k to radix-10^l. It might be done, using much faster algorithms
> than already used, and transparently improve efficiency of multiplying
> and printing/reading big integers.

That would be a good project, if someone is available to mentor it.
(Tim Peters?)

> Next thing I would add is multi precision floating point type to the
> core and fraction type, which in some cases highly improves operations,
> which would have to be done using floating point instead.
> Of course, math module will need update to support multi precision
> floating points, and with that, one could compute asin or any other
> function provided with math with precision limited by memory and time.
> It would be also good idea to add function which computes pi and exp
> with unlimited precision.

I would suggest doing this as a separate module first, rather than as
a patch to the Python core.

Can you show us some practical applications of these operations?

> And last thing - It would be nice to add some number-theory functions to
> math module (or new one), like prime-tests, factorizations etc.

Probably better a new module. But how many people do you think need these?

> Every of above improvements would be coded in pure C, and without using
> external libraries, so portability of python won't be cracked, and no
> new dependencies will be added.

Great -- that's important!

> I am waiting for your responses about my ideas, which of these you think
> are good, which poor etc. Main reason I am posting my question here is
> that, I am not sure, how much are you willing to change the core of the
> python.
>
> At the end, let my apologize for my poor English, I am trying to do my best.

No problem. We can understand you fine!

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

Guido van Rossum wrote:
> Sorry Nick, but you've still got it backwards. The name of the
> decorator shouldn't indicate the type of the return value (of calling
> the decorated generator) -- it should indicate how we think about the
> function. Compare @staticmethod and @classmethod -- the return type
> doesn't enter into it. I think of the function/generator itself as the
> context manager; it returns a context.

Let me have another go. . .

One of the proposals when Raymond raised the issue of naming the PEP 343 
protocol was to call objects with "__enter__"/"__exit__" methods "contexts". 
This was rejected because there were too many things (like decimal.Context) 
that already used that name but couldn't easily be made to fit the new 
definition. So we settled on calling them "context managers" instead.

This wasn't changed by the later discussion that introduced the __context__ 
method. Instead, the new term "manageable context" (or simply "context") was 
introduced to mean "anything with a __context__ method". This was OK, because 
existing context objects like decimal.Context could easily add a context 
method to return an appropriate context manager.

Notice that in *both* approved versions of PEP 343 (before and after the 
inclusion of the __context__ method) the name of the decorator matched the 
name of the kind of object returned by the decorated generator function.

*THIS ALL CHANGED AT PYCON* (at least, I assume that's where it happened - it 
sure didn't happen on this list, and the timing is about right).

During implementation, the meanings of "context" and "context manager" were 
swapped from the meanings in the approved PEP, leading to the current 
situation where decimal.Context is actually not, in fact, a context. These 
meanings were then the ones included in the checked in documentation for 
contextlib, and in PJE's recent update to PEP 343 itself.

However, *despite* the meanings of the two terms being swapped, the decorator 
kept the same name. This means that when using a generator to create a 
"context manager" like decimal.Context under the revised terminology, you are 
forced to claim that the __context__ method is itself a context manager:

   class Context(object):
  # Actually a context manager, despite the class name

  @contextlib.contextmanager
  def __context__(self):
  # Actually a context, despite the decorator name
  newctx = self.copy()
  oldctx = decimal.getcontext()
  decimal.setcontext(newctx)
  try:
  yield newctx
  finally:
  decimal.setcontext(oldctx)

I also note that the decimal module in 2.5a1 actually uses the originally 
approved PEP 343 terminology, calling the object returned from __context__ a 
ContextManager.

And all of this is why I believe we need to either fix the documentation to 
use the terminology used in the PEP at the time of approval, or else finish 
the job of swapping the two terms and change the name of the decorator. Having 
remembered why we picked "context manager" over "context" in the first place, 
my preference is strongly for reverting to the original terminology.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bin codec + EOF

[Guido van Rossum]

On 4/21/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> yeah, i came to realize nothing helpful will ever come out from this list,
> so i might as well stop trying.

Thanks for your encouraging words. Now go away. (Just returning your
polite banter.)

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Visual studio 2005 express now free

[Guido van Rossum]

Microsoft just announced that Visual Studio 2005 express will be free
forever, including the IDE and the optimizing C++ compiler. (Not
included in the "forever" clause are VS 2007 or later versions.)

Does this make a difference for Python development for Windows?

http://msdn.microsoft.com/vstudio/express/

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

[Greg Ewing]

Guido van Rossum wrote:
> You
> can't blame KDE for providing mechanisms that only work in the KDE
> world. It's fine for Python to provide Python-specific solutions for
> issues that have no cross-platform native solution.

Also keep in mind that we're talking about resources
used internally by the application. They don't *need*
to be accessible outside the application. So I don't
think the KDE argument applies here.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

[Greg Ewing]

Martin v. Löwis wrote:
> Greg Ewing wrote:
> 
>>>The "resources" name is actually quite a common meme;
>>
>>I believe it goes back to the original Macintosh, 
>
> I can believe that history. Still, I thought a resource
> is something you can exhaust;

Haven't you heard the term "renewable resource" ?-)

In the real world, yes, most resources will eventually
become exhausted, but I don't think it's a necessary
part of the meaning. It's just something that you
exploit, or make use of.

BTW, in the game programming industry the in-vogue
term at the moment seems  to be "asset", which has
even more inappropriate connotations. Or perhaps
not, if you're a commercial entity that attaches a
dollar value to all your intellectual property...

> the fork should have been named "data fork"

Except that's what they call the *other* fork
(equivalent to the only "fork" on systems that
don't have forks).

> or just "second fork".

But then the relevant Toolbox module would have to
have been called the Second Fork Manager, which
sounds like an API for use by dining philosophers. :-)

FWIW, Apple seem to be deprecating the use of
resource forks these days, and the Resource
Manager, which is a bit sad. It was *fun*
programming the Mac back when it was quirky
as hell and like nothing else on the planet.
Frustrating at times, but fun!

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Mateusz Rukowicz]

Guido van Rossum wrote:

>On 4/21/06, Mateusz Rukowicz <[EMAIL PROTECTED]> wrote:
>  
>
>>Next thing I would add is multi precision floating point type to the
>>core and fraction type, which in some cases highly improves operations,
>>which would have to be done using floating point instead.
>>Of course, math module will need update to support multi precision
>>floating points, and with that, one could compute asin or any other
>>function provided with math with precision limited by memory and time.
>>It would be also good idea to add function which computes pi and exp
>>with unlimited precision.
>>
>>
>
>I would suggest doing this as a separate module first, rather than as
>a patch to the Python core.
>
>Can you show us some practical applications of these operations?
>
>  
>
Multi precision float is mostly used by physicians and mathematicians, 
interpreted languages are particularly good for physics simulations, in 
which small error would grow so much, that results are useless. Rational 
numbers would be used in codes where precision is of 
critical-importance, and one cannot accept rounding of results. So 
fraction (and also multi precision floating) would mostly be used in 
linear-programming algorithms, like solving set of equations or some 
optimizing methods.

>>And last thing - It would be nice to add some number-theory functions to
>>math module (or new one), like prime-tests, factorizations etc.
>>
>>
>
>Probably better a new module. But how many people do you think need these?
>
>  
>
Mostly cryptography would exploit fast number-theory algorithms. Adding 
these as a module would boost and make easier to code everything which 
is related to cryptography, such as ssl, rsa etc. Also hobbyist looking 
for huge primes etc. would appreciate that, but it is not main purpose 
of these ;).

I understand that most of these improvements have quite limited 
audience, but I still think python should be friendly to them ;)

Best regards,
Mateusz Rukowicz.

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

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

[Greg Ewing]

Martin v. Löwis wrote:

> I can readily believe that package authors indeed see this as
> a simplification, but I also see an increased burden on system
> admins in return.

There are two conflicting desires here. Package authors
don't want to have to make M different kinds of package
for M different systems. System administrators don't want
to have to deal with N different kinds of package originating
from N different software development environments.

What can be done about this? Maybe some kind of babel
server in the middle, which knows how to convert between
all the different packaging formats. Authors submit
packages in the form which is easiest for them to
produce, and users request packages in the form which
is easiest for them to install. The server does whatever
is necessary to convert between them.

Perhaps something along these lines could be incorporated
into the cheeseshop? So you could ask e.g. for your
favourite package in .rpm format, and if it only knew
how to get it in .egg format it would feed it to a
handy bdist-bot for conversion.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

[Greg Ewing]

Phillip J. Eby wrote:

> By now, however, the term is popularly used with GUI toolkits of all 
> kinds to mean essentially read-only data files that are required by a 
> program or library to function, but which are not directly part of the 
> code.

It's just occurred to me that there's another thread
to the history of this term: the X window system's
use of the term "resource" to mean essentially a
user-configurable setting. This is probably where
the usage you're referring to comes from, since
Gtk and the ilk are fairly deeply rooted in X.

This is really quite a different idea, although
there's some overlap because X applications are
typically distributed with a "resources" file
containing default values for the settings, and
won't work without there being some version of
this file available.

However, the sense we're talking about is more
like the Mac one, where resources are an integral
part of the program just as much as the code is,
and have every right to be kept with the code.

Indeed, in a classic 68K Mac application, the code
literally WAS a resource. The 68K machine code was
kept in the resource fork in resources of type
"CODE". The data fork of an application was usually
empty.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools in 2.5.

[Paul Moore]

On 4/21/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > 2. Distributors will supply .egg files rather than bdist_wininst
> > installers (this is already happening).
>
> Really people should at least be uploading source packages in addition
> to eggs; it's certainly not hard to do so.

Windows user perspective: So what? If there's a C extension involved,
I can't build it on at least one machine I use (so I build elsewhere
and move the installer over). If external libraries are involved, I
quite likely don't have .lib files, headers, etc available.

I know this isn't such an issue on Unix. But the rise of bdist_wininst
installers on Windows was a HUGE benefit. I remember the nightmares I
used to have finding binaries for things I couldn't build myself (and
I'm atypical - I have lots of tools that most people don't).

Nowadays, there are more and more packages I can't find bdist_wininst
installers for, again. (Turbogears and PyProtocols are the two I
recall offhand). I can find eggs, but to use them I lose the package
management I *like*. Please don't tell me that Windows' Add/Remove
Programs is limited or incomplete - it does exactly what I want, and I
have no need to change. And I don't want a mix - I want *everything*
under my Python install directory to be managed by an Add/Remove
Programs entry.

I'm quite happy to convert eggs to bdist_wininst installers (or MSI
installers) by hand. That's a mechanical task, in theory, and as I'm
catering for my preferences, I see no reason to expect someone else to
do that for me. But I can't build from scratch, so don't force me to.

> Perhaps a distributor quick intro needs to be written for the standard
> library.  Something short; both distutils and setuptools documentation
> are pretty long, and for someone who just has some simple Python code to
> get out it's overwhelming.

Agreed. Maybe I'll knock up a simple set of setup.py templates (for a
pure-python module, a simple package, and a C extension, maybe) and
put them on the Wiki. I'll add it to my TODO list.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Module names in Python: was Re: python 2.5alpha and naming schemes

[Dennis Heuer]

There's also a difflib though the module doesn't look like a wrapper
for diff. The math module is not called mathlib though. Python is
quite inconsistent here. On the one hand it tries to use
human-understandable terms and on the other hand it takes the easy
approach, which means it falls back to common ways of naming in
the C world.

However, the module hashlib is not really a 'hashing library'. The term
'hash' is quite abstract and not really appropriate. The term 'lib'
is quite displaced in the python world. 'hashmod' would be more
appropriate but also very bad.

The hashing algorithms can be used for very different things. They are
mainly just converters. Hashing is only a buzzword-like synonym for
'encoding without the chance for decoding'. Possibly there should
be an extra section (main module) called 'converters', which assorts all
the en/decoders like punycode, zip, or md5 in submodules. The 'hashlib'
submodule could be called 'cryptographic', for example:

converters.cryptographic.sha

This is possibly too long but one should keep this in the back of one's
mind because python could profit from some renaming here and there to
get closer to its goal to be more human-understandable--and well-sorted.

'math.cryptography' or at least 'math.hash' would work as well.

Dennis


On Thu, 20 Apr 2006 18:00:49 -0700
"Gregory P. Smith" <[EMAIL PROTECTED]> wrote:

> > Module names like hashlib are not python-like too (too c/lowlevel-like).
> 
> what is python-like?
> 
> hashlib was chosen because it is a library of hash functions and
> hash() is already taken as a builtin function (otherwise i'd leave off
> the lib).
> 
> -g
> 
> 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] windows buildbot failures

[Jérôme Laheurte]

Le 20 avr. 06 à 22:25, Martin v. Löwis a écrit :

> Jérôme Laheurte wrote:
>> Sorry I'm late, but something like "os.popen('taskkill.exe /F /IM
>> python_d.exe')" would have worked; we use this at work.
>
> Thanks, I didn't know about it. Is it available on Windows 2000,
> too? (because the system in question is Windows 2000, and I see
> it on a "What's new in Windows XP" page)

Ah, no, it's only available in XP. There are some alternatives though:

http://www.robvanderwoude.com/index.html

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

Re: [Python-Dev] Distutils thoughts

[Paul Moore]

On 4/21/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> While we're on the subject of distutils revision, here
> are a few things I've encountered about distutils which
> seem less than desirable.
>
> * There doesn't seem to be a way of supplying options
>on the command line for anything except the top-level
>command. Sometimes, e.g. I want to do an "install" but
>override some options for the "build_ext" that gets
>invoked by the install. But distutils won't let me,
>because those options are not recognised by the
>"install" command itself.

I do things like

python setup.py build --compiler=mingw32 bdist_wininst

which seem to work for me. Is that any help?

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Guido van Rossum]

On 4/21/06, Mateusz Rukowicz <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> >On 4/21/06, Mateusz Rukowicz <[EMAIL PROTECTED]> wrote:
> >>Next thing I would add is multi precision floating point type to the
> >>core and fraction type, which in some cases highly improves operations,
> >>which would have to be done using floating point instead.
> >>Of course, math module will need update to support multi precision
> >>floating points, and with that, one could compute asin or any other
> >>function provided with math with precision limited by memory and time.
> >>It would be also good idea to add function which computes pi and exp
> >>with unlimited precision.
> >
> >I would suggest doing this as a separate module first, rather than as
> >a patch to the Python core.
> >
> >Can you show us some practical applications of these operations?
> >
> Multi precision float is mostly used by physicians and mathematicians,

(Aside: you probably mean physicist, someone who practices physics. A
physician is a doctor; don't ask me why. :-)

> interpreted languages are particularly good for physics simulations, in
> which small error would grow so much, that results are useless.

We already have decimal floating point which can be configured to use
however many digits of precision you want. Would this be sufficient?
If you want more performance, perhaps you could tackle the very useful
project of translating decimal.py into C?

> Rational numbers would be used in codes where precision is of
> critical-importance, and one cannot accept rounding of results. So
> fraction (and also multi precision floating) would mostly be used in
> linear-programming algorithms, like solving set of equations or some
> optimizing methods.

I'm not sure I see the value of rational numbers implemeted in C;
they're easy to write in Python and all the time goes into division of
two ints which is already implemented in C.

> >>And last thing - It would be nice to add some number-theory functions to
> >>math module (or new one), like prime-tests, factorizations etc.
> >
> >Probably better a new module. But how many people do you think need these?
> >
> Mostly cryptography would exploit fast number-theory algorithms. Adding
> these as a module would boost and make easier to code everything which
> is related to cryptography, such as ssl, rsa etc. Also hobbyist looking
> for huge primes etc. would appreciate that, but it is not main purpose
> of these ;).

Have you looked at the existing wrappers around OpenSSL, such as
pyopenssl and m2crypto? ISTM that these provide most of the needed
algorithms, already coded in open source C.

> I understand that most of these improvements have quite limited
> audience, but I still think python should be friendly to them ;)

Sure. The question is, if there are more student applications than
Google wants to fund, which projects will be selected? I would
personally vote for the projects that potentially help out the largest
number of Python users.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Guido van Rossum]

OK, now I'm confused. I hope that Phillip understands this and will
know what to do.

On 4/21/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Sorry Nick, but you've still got it backwards. The name of the
> > decorator shouldn't indicate the type of the return value (of calling
> > the decorated generator) -- it should indicate how we think about the
> > function. Compare @staticmethod and @classmethod -- the return type
> > doesn't enter into it. I think of the function/generator itself as the
> > context manager; it returns a context.
>
> Let me have another go. . .
>
> One of the proposals when Raymond raised the issue of naming the PEP 343
> protocol was to call objects with "__enter__"/"__exit__" methods "contexts".
> This was rejected because there were too many things (like decimal.Context)
> that already used that name but couldn't easily be made to fit the new
> definition. So we settled on calling them "context managers" instead.
>
> This wasn't changed by the later discussion that introduced the __context__
> method. Instead, the new term "manageable context" (or simply "context") was
> introduced to mean "anything with a __context__ method". This was OK, because
> existing context objects like decimal.Context could easily add a context
> method to return an appropriate context manager.
>
> Notice that in *both* approved versions of PEP 343 (before and after the
> inclusion of the __context__ method) the name of the decorator matched the
> name of the kind of object returned by the decorated generator function.
>
> *THIS ALL CHANGED AT PYCON* (at least, I assume that's where it happened - it
> sure didn't happen on this list, and the timing is about right).
>
> During implementation, the meanings of "context" and "context manager" were
> swapped from the meanings in the approved PEP, leading to the current
> situation where decimal.Context is actually not, in fact, a context. These
> meanings were then the ones included in the checked in documentation for
> contextlib, and in PJE's recent update to PEP 343 itself.
>
> However, *despite* the meanings of the two terms being swapped, the decorator
> kept the same name. This means that when using a generator to create a
> "context manager" like decimal.Context under the revised terminology, you are
> forced to claim that the __context__ method is itself a context manager:
>
>class Context(object):
>   # Actually a context manager, despite the class name
>
>   @contextlib.contextmanager
>   def __context__(self):
>   # Actually a context, despite the decorator name
>   newctx = self.copy()
>   oldctx = decimal.getcontext()
>   decimal.setcontext(newctx)
>   try:
>   yield newctx
>   finally:
>   decimal.setcontext(oldctx)
>
> I also note that the decimal module in 2.5a1 actually uses the originally
> approved PEP 343 terminology, calling the object returned from __context__ a
> ContextManager.
>
> And all of this is why I believe we need to either fix the documentation to
> use the terminology used in the PEP at the time of approval, or else finish
> the job of swapping the two terms and change the name of the decorator. Having
> remembered why we picked "context manager" over "context" in the first place,
> my preference is strongly for reverting to the original terminology.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
> ---
>  http://www.boredomandlaziness.org
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Removing Python 2.4 -m switch helpers from import.c

[Nick Coghlan]

With the -m switch switching to using the runpy module in 2.5, the two private 
helper functions exposed by import.c (_PyImport_FindModule & 
_PyImport_IsScript) aren't needed anymore.

Should I remove them, since they're essentially dead code now?

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools in 2.5.

[Greg Ewing]

Phillip J. Eby wrote:
> You seem to believe that there are other 
> things more important than making things Just Work for this audience.

While it's clearly a good thing when something "just
works", I don't think that this should be the only goal.
Just as important to my mind -- probably even more
important -- is what the experience is like when things
*don't* work. Because in such a varied world, you're
never going to make everything "just work" for
everyone all the time.

When I type "make install" and something goes wrong,
I find that there are two different kinds of experience
I typically get:

(1) I look at the Makefile, and find that it's written
in a straightforward style. I can see what it's trying
to do, find the problem, fix it, "make install" again
and everything is all right.

(2) I look at the Makefile and find that it's full of
macros which get expanded and scripts that generate more
files that get macro expanded again and wrapped up in
duct tape and eventually somehow build something. I
haven't a clue how it's supposed to work and don't have
the time or inclination to figure it out. I give up.

It sounds like (2) is the sort of experience that some
people have been having with distutils.

If that's true, then in the long run you are not going
to improve matters by wrapping distutils up in yet
another layer of magic, indirection and duct tape.
You might succeed in making a certain number of things
work that didn't work before. But when something breaks,
it won't be any easier to fix than the original distutils,
because it contains distutils as a major component.

Rather than just trying to make a few more things "just
work", we should be trying hard to improve the "just
doesn't work" case. To do that, we need *LESS* magic,
not more. We need to do things in as straightforward,
obvious and transparent a way as possible -- so that
when it goes wrong, you can see why it is going wrong
and how to make it go right.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools in 2.5.

[Paul Moore]

On 4/20/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> - they're currently discussing whether to use stricter version requirements
> for individual components, to increase the chance that people end up using
> a combination that someone else has actually tested.

That makes me quite nervous. While I understand that there are support
issues, I don't like the idea of a package that refuses to run, simply
because I have version 2.1 of something it uses, and the package
insists on 2.0 - without any concrete reason beyond "we haven't tested
that version yet". We have to deal with this sort of thing a lot at
work (in a non-Python context), and it's a support nightmare of its
own.

And no, I don't want to install the 2 versions side-by-side. Ian
Bicking complained recently about the "uncertainty" of multiple
directories on sys.path meaning you can't be sure which version of a
module you get. Well, having 2 versions of a module installed and
knowing that which one is in use depends on require calls which get
issued at runtime worries me far more.

[Please note, I have no problem with people who are happy to work like
this. It's just that I don't, and I want to make sure that the new
ways of working promoted by setuptools don't ignore my needs. It's
even fine to consider my needs and decide to not support them, but
let's note the fact that this was done... :-)]

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools in 2.5.

[Greg Ewing]

Phillip J. Eby wrote:
> So, this is a nice 
> example of how complex it can be to extend the distutils in ways that don't 
> break random popular packages.

It's probably also an example of what happens when
something doesn't have a well-documented extension
interface -- nobody can tell what's an implementation
detail and what isn't.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils thoughts

[Greg Ewing]

Paul Moore wrote:

> I do things like
> 
> python setup.py build --compiler=mingw32 bdist_wininst
> 
> which seem to work for me. Is that any help?

Possibly. I'll have to try it next time I have the
problem and see.

BTW, does that do anything different from

python setup.py build --compiler=mingw32
python setup.py bdist_wininst

? If so, that's rather unintuitive and could do
with documenting more clearly.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Greg Ewing]

Nick Coghlan wrote:

> During implementation, the meanings of "context" and "context manager" were 
> swapped from the meanings in the approved PEP, leading to the current 
> situation where decimal.Context is actually not, in fact, a context.

That's rather disappointing. I *liked* the way that
decimal.Context was a context. Was there a conscious
choice to swap the terms, or did it happen by accident?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools in 2.5.

[Greg Ewing]

Paul Moore wrote:
> Well, having 2 versions of a module installed and
> knowing that which one is in use depends on require calls which get
> issued at runtime worries me far more.

There's also the problem of having module A which requires
version 2.0 or earlier of Z, and B which requires 2.1 or later
of Z, and you want to use C which requires both A and B...

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils thoughts

[Thomas Heller]

Greg Ewing wrote:
> Paul Moore wrote:
> 
>> I do things like
>>
>> python setup.py build --compiler=mingw32 bdist_wininst
>>
>> which seem to work for me. Is that any help?
> 
> Possibly. I'll have to try it next time I have the
> problem and see.
> 
> BTW, does that do anything different from
> 
> python setup.py build --compiler=mingw32
> python setup.py bdist_wininst
> 
> ? If so, that's rather unintuitive and could do
> with documenting more clearly.

In principle, it does the same.

In practice, it doesn't because 'bdist_wininst' will instantiate
a compiler (by default MSVC) to check whether the extensions need to be
build (built?) or are up to date.  Which will fail unless MSVC is installed.

The best solution is to configure the mingw32 compiler in the distutils
configuration file.

Thomas

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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

Greg Ewing wrote:
> Nick Coghlan wrote:
> 
>> During implementation, the meanings of "context" and "context manager" were 
>> swapped from the meanings in the approved PEP, leading to the current 
>> situation where decimal.Context is actually not, in fact, a context.
> 
> That's rather disappointing. I *liked* the way that
> decimal.Context was a context. Was there a conscious
> choice to swap the terms, or did it happen by accident?

That's what I'm currently trying to find out - whether or not this was a 
deliberate decision made at PyCon. Conference sprints are great for getting 
things done, but they do occasionally lead to decisions getting made without 
being properly recorded :)

The terminology in the current docs is more natural in some ways than what the 
PEP settled on (mainly due to the __context__ method), so I'm wondering if the 
downside that lead us to pick the slightly more awkward terminology may have 
been forgotten at the time of implementation.

Unfortunately this kind of discussion can take days via email*, even though it 
would probably only take ten minutes or so in person - not getting any 
immediate feedback when your point of view isn't being understood really slows 
things down.

I'm just glad AMK noticed the discrepancy - I completely missed it when I read 
the contextlib docs (I suspect my brain was being 'helpful' and automatically 
filled in what I expected to see rather than what was actually there).

Cheers,
Nick.

* s/can take/already has taken/ ;)

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] patch #1454481 - runtime tunable thread stack size

[Andrew MacIntyre]

http://www.python.org/sf/1454481

I would like to see this make it in to 2.5.  To that end I was hoping to
elicit any review interest beyond Martin and Hye-Shik, both of whom I 
thank for their feedback.

As I can't readily test on Windows (in particular) or Linux I would
appreciate some kind soul(s) actually testing to make sure that the patch
doesn't break builds on those platforms.

Thanks,
Andrew.

-
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils thoughts

[Greg Ewing]

Thomas Heller wrote:

> The best solution is to configure the mingw32 compiler in the distutils
> configuration file.

That's the same conclusion I came to. But it's
unintuitive that you can't also do the same
thing using command line options, or if you
can, it's not obvious how to do it.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Aahz]

On Fri, Apr 21, 2006, Mateusz Rukowicz wrote:
>
> Next thing I would add is multi precision floating point type to
> the core and fraction type, which in some cases highly improves
> operations, which would have to be done using floating point instead.
> Of course, math module will need update to support multi precision
> floating points, and with that, one could compute asin or any other
> function provided with math with precision limited by memory and
> time.  It would be also good idea to add function which computes pi
> and exp with unlimited precision.  And last thing - It would be nice
> to add some number-theory functions to math module (or new one), like
> prime-tests, factorizations etc.

To echo and amplify what Guido said: an excellent project would be to
rewrite the decimal module in C.  Another option would be to pick up and
enhance either of the GMP wrappers:

http://gmpy.sourceforge.net/
http://www.egenix.com/files/python/mxNumber.html

That would also deal with your suggestion of rational numbers.

Working with long ints would also be excellent, but I'd hesitate to
tackle that unless Tim Peters volunteers to help (because there may be
special implementation constraints).
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"Argue for your limitations, and sure enough they're yours."  --Richard Bach
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[A.M. Kuchling]

On Fri, Apr 21, 2006 at 07:31:35PM +1000, Nick Coghlan wrote:
> fit the new definition. So we settled on calling them "context managers" 
> instead.
 ... 
> method. Instead, the new term "manageable context" (or simply "context") 
> was introduced to mean "anything with a __context__ method". This was OK, 

Meaning that 'manageable context' objects create and destroy 'context
managers'...  My view is still that 'context manager' is a terrible
name when used alongside objects called 'contexts': the object doesn't
manage anything, and it certainly doesn't manage contexts -- in fact
it's created by 'context' objects.

Perhaps we need to do some usability tests.  Go to a local user group,
explain the 'with' statement and the necessary objects using __foo__
instead of __context__, provide three or four pairs of names, and then
ask the audience which set of names seems most sensible.

For the What's New, I'm now beginning to think the text should say
'objects that have a __context__() method', and then refer to either
contexts or context managers (whichever way the decision goes) for the
objects with enter/exit, to avoid this confusion.

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Alex Martelli]

On Apr 21, 2006, at 7:46 AM, Aahz wrote:

> On Fri, Apr 21, 2006, Mateusz Rukowicz wrote:
>>
>> Next thing I would add is multi precision floating point type to
>> the core and fraction type, which in some cases highly improves
>> operations, which would have to be done using floating point instead.
>> Of course, math module will need update to support multi precision
>> floating points, and with that, one could compute asin or any other
>> function provided with math with precision limited by memory and
>> time.  It would be also good idea to add function which computes pi
>> and exp with unlimited precision.  And last thing - It would be nice
>> to add some number-theory functions to math module (or new one), like
>> prime-tests, factorizations etc.
>
> To echo and amplify what Guido said: an excellent project would be to
> rewrite the decimal module in C.  Another option would be to pick  
> up and
> enhance either of the GMP wrappers:
>
> http://gmpy.sourceforge.net/
> http://www.egenix.com/files/python/mxNumber.html
>
> That would also deal with your suggestion of rational numbers.

GMP is covered by LGPL, so must any such derivative work (presumably  
ruling it out for embedding in Python's core itself). That being  
said, as gmpy's author, I'd be enthusiastically happy to mentor  
anybody who wants to work on gmpy or other multiprecision arithmetic  
extension for Python.


Alex

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

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

[Martin v. Löwis]

Ronald Oussoren wrote:
>> That doesn't require Eggs to be single-file zipfiles; deleting a
>> directory would work just as will (and I believe it will work with
>> ez_install, too).
> 
> Egg directories (which are basically just the same as packages using 
> .pth files) also work for this and that's what I usually install.
> Setuptools can work with python extension inside .zip files, but I'm
> not entirely comfortable with that.

It's primarily the .egg *files* that I dislike. I'm can accept
the .egg directories.

Regards,
Martin

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

Re: [Python-Dev] windows buildbot failures

[Martin v. Löwis]

Jérôme Laheurte wrote:
> Ah, no, it's only available in XP. There are some alternatives though:
> 
> http://www.robvanderwoude.com/index.html

Sure. Writing my own one wasn't that difficult, in the end, either
(except that I overlooked that the API I used first exists in XP
and later only).

regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000-checkins] r45617 - in python/branches/p3yk/Lib/plat-mac/lib-scriptpackages: CodeWarrior/CodeWarrior_suite.py CodeWarrior/__init__.py Explorer/__init__.py Finder/Container

[Thomas Wouters]

On 4/21/06, guido.van.rossum  wrote:
The hardest part was fixing two mutual recursive imports;somehow changing "import foo" into "from . import foo" wherefoo and bar import each other AND both are imported from __init__.py caused things to break.  Bah.
Hm, this is possibly a flaw in the explicit relative import mechanism. Normal circular imports work because a module object is stuffed into sys.modules before any code for the module is executed, so the next 'import' of that module just finds the half-loaded module object. I guess 'from . import name' really looks at the package contents, though, and there, the module isn't stored until it's done loading. I'm not sure why it raises a 'cannot import name' exception instead of recursing into a spiral of death, but I guess that's a good thing. :)
Should this be fixed, or is it an esoteric enough case that I shouldn't bother?-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Mateusz Rukowicz]

Alex Martelli wrote:

>
> On Apr 21, 2006, at 7:46 AM, Aahz wrote:
>
>> On Fri, Apr 21, 2006, Mateusz Rukowicz wrote:
>>
>>>
>>> Next thing I would add is multi precision floating point type to
>>> the core and fraction type, which in some cases highly improves
>>> operations, which would have to be done using floating point instead.
>>> Of course, math module will need update to support multi precision
>>> floating points, and with that, one could compute asin or any other
>>> function provided with math with precision limited by memory and
>>> time.  It would be also good idea to add function which computes pi
>>> and exp with unlimited precision.  And last thing - It would be nice
>>> to add some number-theory functions to math module (or new one), like
>>> prime-tests, factorizations etc.
>>
>>
>> To echo and amplify what Guido said: an excellent project would be to
>> rewrite the decimal module in C.  Another option would be to pick  up 
>> and
>> enhance either of the GMP wrappers:
>>
>> http://gmpy.sourceforge.net/
>> http://www.egenix.com/files/python/mxNumber.html
>>
>> That would also deal with your suggestion of rational numbers.
>
>
> GMP is covered by LGPL, so must any such derivative work (presumably  
> ruling it out for embedding in Python's core itself). That being  
> said, as gmpy's author, I'd be enthusiastically happy to mentor  
> anybody who wants to work on gmpy or other multiprecision arithmetic  
> extension for Python.
>
Rewriting decimal module in C is not far from my initial idea, and I am 
quite happy about that, you think it's good idea.
If I was doing it, I would write all needed things myself - I am quite 
experienced in coding multi precision computation algorithms (and all 
kind of algorithms at all).

>Working with long ints would also be excellent, but I'd hesitate to
>tackle that unless Tim Peters volunteers to help (because there may be
>special implementation constraints).

I am quite confident, that I would be able to make those changes 
transparently, that is - representation of long int wouldn't change. And 
as far as I saw in the code it's quite straightforward (actually, it 
would be strange otherwise). But of course it's up to you. Anyway, I 
hope it will be possible to add those changes.

I guess that's quite enough for SoC project, but I hope, it will be 
possible to add some of my initial ideas anyway.

Best regards,
Mateusz Rukowicz.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000-checkins] r45617 - in python/branches/p3yk/Lib/plat-mac/lib-scriptpackages: CodeWarrior/CodeWarrior_suite.py CodeWarrior/__init__.py Explorer/__init__.py Finder/Container

[Guido van Rossum]

On 4/21/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
> On 4/21/06, guido.van.rossum  wrote:
> > The hardest part was fixing two mutual recursive imports;
> > somehow changing "import foo" into "from . import foo" where
> > foo and bar import each other AND both are imported from __init__.py
> caused things to break.  Bah.
>
> Hm, this is possibly a flaw in the explicit relative import mechanism.
> Normal circular imports work because a module object is stuffed into
> sys.modules before any code for the module is executed, so the next 'import'
> of that module just finds the half-loaded module object. I guess 'from .
> import name' really looks at the package contents, though, and there, the
> module isn't stored until it's done loading. I'm not sure why it raises a
> 'cannot import name' exception instead of recursing into a spiral of death,
> but I guess that's a good thing. :)

That's what I thought. But I believe I reproduced it in 2.4 as well.
I'm not 100% sure but I've got a feeling that the situation is
actually due to these imports happening *while __init__ is loading*.
When P is a package and M is a module, "from P import M" seems to
first check that sys.modules["P.M"] exists, but then it somehow asks
for P.M instead for sys.modules["P.M"]. At least that's how I cam up
with the fix (which sets P.M from inside M) and the fix made the
problem go away.

> Should this be fixed, or is it an esoteric enough case that I shouldn't
> bother?

I do think it ought to be fixed, and in 2.5 as well.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000-checkins] r45617 - in python/branches/p3yk/Lib/plat-mac/lib-scriptpackages: CodeWarrior/CodeWarrior_suite.py CodeWarrior/__init__.py Explorer/__init__.py Finder/Container

[Guido van Rossum]

On 4/21/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
> On 4/21/06, guido.van.rossum  wrote:
> > The hardest part was fixing two mutual recursive imports;
> > somehow changing "import foo" into "from . import foo" where
> > foo and bar import each other AND both are imported from __init__.py
> caused things to break.  Bah.
>
> Hm, this is possibly a flaw in the explicit relative import mechanism.
> Normal circular imports work because a module object is stuffed into
> sys.modules before any code for the module is executed, so the next 'import'
> of that module just finds the half-loaded module object. I guess 'from .
> import name' really looks at the package contents, though, and there, the
> module isn't stored until it's done loading. I'm not sure why it raises a
> 'cannot import name' exception instead of recursing into a spiral of death,
> but I guess that's a good thing. :)

That's what I thought. But I believe I reproduced it in 2.4 as well.
I'm not 100% sure but I've got a feeling that the situation is
actually due to these imports happening *while __init__ is loading*.
When P is a package and M is a module, "from P import M" seems to
first check that sys.modules["P.M"] exists, but then it somehow asks
for P.M instead for sys.modules["P.M"]. At least that's how I cam up
with the fix (which sets P.M from inside M) and the fix made the
problem go away.

> Should this be fixed, or is it an esoteric enough case that I shouldn't
> bother?

I do think it ought to be fixed, and in 2.5 as well.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000-checkins] r45617 - in python/branches/p3yk/Lib/plat-mac/lib-scriptpackages: CodeWarrior/CodeWarrior_suite.py CodeWarrior/__init__.py Explorer/__init__.py Finder/Container

[Phillip J. Eby]

At 06:26 PM 4/21/2006 +0200, Thomas Wouters wrote:

>On 4/21/06, guido.van.rossum 
><python-3000-checkins@python.org> 
>wrote:
>>The hardest part was fixing two mutual recursive imports;
>>somehow changing "import foo" into "from . import foo" where
>>foo and bar import each other AND both are imported from __init__.py 
>>caused things to break.  Bah.
>
>Hm, this is possibly a flaw in the explicit relative import mechanism.

Actually, this sounds rather like a problem that happens in Python 2.4 as well.

If you have a package 'foo' containing modules 'bar' and 'baz', and 
foo/__init__.py imports both bar and baz, then 'import foo.bar' will fail 
inside of baz.  You have to use 'from foo import bar' or it doesn't 
work.  We run into this a lot in Chandler, which tries to expose package 
APIs from the package __init__ modules.

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

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

[Martin v. Löwis]

Greg Ewing wrote:
> Guido van Rossum wrote:
>> You
>> can't blame KDE for providing mechanisms that only work in the KDE
>> world. It's fine for Python to provide Python-specific solutions for
>> issues that have no cross-platform native solution.
> 
> Also keep in mind that we're talking about resources
> used internally by the application. They don't *need*
> to be accessible outside the application. So I don't
> think the KDE argument applies here.

They might need to be available outside "Python". Two use cases:

1. The application embeds an sqlite database. Even though it
   knows how to get at the data, it can't use it, because the
   sqlite3 library won't accept
   .../foo-1.0.egg/resources/the_data
   (or some such) as a database name, if foo-1.0.egg is a ZIP file.

   If the installed application was a set of files, that would work.

2. The application embeds an SGML DTD (say, HTML). In order to
   perform validation, it invokes nsgmls on the host system.
   It cannot pass the SGML catalog to nsgmls (using the -C option)
   since you can't refer to DTD files inside ZIP files inside
   an SGML catalog.

   If this was a bunch of installed files, it would work.

3. The application includes an SSL certificate. It can't pass it
   to socket.ssl, since OpenSSL expects a host system file name,
   not a fragment of a zip file.

   If this was installed as files, it would work.

This is precisely what happens in KDE: you have konqueror happily
browse an SMB directory, double-click on a .xls file, OpenOffice
starts and can't access the file it was started with. It doesn't
matter to the user that there is "a good reason" for that.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] setuptools in 2.5.

[Jim Jewett]

M.-A. Lemburg wrote:

>There's really nothing wrong with the standard distutils
>two step process:

>1. download and unzip the source file

On windows, the closest thing to a standard unzip is winzip.

I have recently found several zip files aimed at windows users which
winzip could not open, though python's tarfile module could.  So the
unzip isn't always trivial.

>2. run "python setup.py install"

setup.py isn't a unique enough name to convince me that things are
easily reversed or repeated.  The distutils are complex enough that my
concern doesn't go away.  (Whether setuptools will be clear enough or
documented enough to actually solve this, I don't yet know.  I have
high hopes.)

Phillip J. Eby wrote:

> Such packages may have customized their installation process
> by extending the distutils, *without* overriding get_outputs().  Since few
> people actually use the --record option for anything important, nobody
> notices when it breaks.

I just searched through the (2.4.2) documentation, and could find no
reference to either get_outputs or --record.  I also looked through
the source, and couldn't find any reference to --record.  (I later
found one in bdist_rpm, but "build a binary for Red Hat Linux" isn't a
natural thing for anyone not on Linux to even try.)

When I did a grep (which I wouldn't do unless I already knew I needed
to worry about it), I finally found a few references in install.py
which boiled down to "nothing happens, but you could get a list of
files if you went through enough contortions".  This looks more like a
debugging aid than something I would have to worry about.

> As for --install-data, just put your data in the packages and use Python
> 2.4's ability to install package data, or one of the pre-existing distutils
> extensions that beat install_data over the head to make it install the data
> with the packages.

Use of a third-party extension (that isn't mentioned in the docs) is
hardly intuitive.  If it is really required, that is far more
intrusive than the stdlib changes setuptools makes.  (Would it only
intrude on the packager, at least?  But then how could he or she be
confident that the package would work on someone else's box?)

-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Mateusz Rukowicz]

Guido van Rossum wrote:

>(Aside: you probably mean physicist, someone who practices physics. A
>physician is a doctor; don't ask me why. :-)
>
>  
>
;) I'll remember ;)

>>interpreted languages are particularly good for physics simulations, in
>>which small error would grow so much, that results are useless.
>>
>>
>
>We already have decimal floating point which can be configured to use
>however many digits of precision you want. Would this be sufficient?
>If you want more performance, perhaps you could tackle the very useful
>project of translating decimal.py into C?
>
>  
>
Yes, it seems like better idea - already written software would benefit 
that transparently. I think I could develop 'margin' ideas later.

>I'm not sure I see the value of rational numbers implemeted in C;
>they're easy to write in Python and all the time goes into division of
>two ints which is already implemented in C.
>
>  
>
Well, quite true ;P

>Have you looked at the existing wrappers around OpenSSL, such as
>pyopenssl and m2crypto? ISTM that these provide most of the needed
>algorithms, already coded in open source C.
>
>  
>
Well, you already convinced me to not do that right now, but I still 
think python would benefit that, and it would be done later on, but this 
discussion may be moved in time.

>>I understand that most of these improvements have quite limited
>>audience, but I still think python should be friendly to them ;)
>>
>>
>
>Sure. The question is, if there are more student applications than
>Google wants to fund, which projects will be selected? I would
>personally vote for the projects that potentially help out the largest
>number of Python users.
>
>  
>
So I think the most valuable of my ideas would be improving long int + 
coding decimal in C. Anyway, I think it would be possible to add other 
ideas later.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Phillip J. Eby]

At 10:51 AM 4/21/2006 -0400, A.M. Kuchling wrote:
>On Fri, Apr 21, 2006 at 07:31:35PM +1000, Nick Coghlan wrote:
> > fit the new definition. So we settled on calling them "context managers"
> > instead.
>  ...
> > method. Instead, the new term "manageable context" (or simply "context")
> > was introduced to mean "anything with a __context__ method". This was OK,
>
>Meaning that 'manageable context' objects create and destroy 'context
>managers'...  My view is still that 'context manager' is a terrible
>name when used alongside objects called 'contexts': the object doesn't
>manage anything, and it certainly doesn't manage contexts -- in fact
>it's created by 'context' objects.

And that's more or less why I wrote the documentation the way I did.

Nick, as I understand your argument, it's that we were previously using the 
term "context manager" to mean "thing with __enter__ and __exit__".  But 
that was *never* my interpretation.

My understanding of "context manager" was always, "thing that you give to a 
with statement".

So to me, when we added a __context__ method, we were creating a *new 
object* that hadn't existed before, and we moved some methods on to 
it.  Thus, "context manager" still meant "thing you give to the with 
statement" -- and that never changed, from my POV.

And that's why I see the argument that we've "reversed" the terminology as 
bogus: to me it's been consistent all along.  We just added another object 
*besides* the context manager.

Note too that the user of the "with" statement doesn't know that this other 
object exists, and in fact sometimes it doesn't actually exist, it's the 
same object.  None of this is relevant for the with-statement user, only 
the context manager.  So there's no reason (IMO) to monkey with the 
definition of "context manager" as "thing you use in a with statement".

Now, I get your point about @contextmanager on a __context__ method, and I 
agree that that seems backwards at first.  What I don't see is how to 
change the terminology to handle that subtlety in a way that doesn't muck 
up the basically simple definitions that are in place now.

If it must be explained, however, I'd rather simply document it in 
contextlib that @contextmanager-decorated functions return an object that 
is both a context manager and a context (or whatever name you want for the 
invisible-behind-the-scenes-thing with enter and exit methods).  Since it 
is possible for an object to be both, that seems to do fine for explaining 
why you can use @contextmanager to define a __context__ method.

I'm definitely open to other terminology for the invisible thing besides 
"context", but I don't care for "managed context" or "manageable context", 
as these aren't much better.  I'm somewhat tempted by "context instance" or 
"context invocation".  E.g, the __context__ method should return a "context 
instance": an object representing a single instance of use of the 
context.  There's a wee hint of suggestion that this means "instance of 
type context", but it's more suggestive of one-time use than "context object".

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

Re: [Python-Dev] python 2.5alpha and naming schemes

[Martin v. Löwis]

Thomas Heller wrote:
> Personally, I *like* the ctypes name.  But I'm open for suggestions,
> and it might have intersting consequences if the Python core package
> would be renamed to something else.
> 
> Any suggestions?

Well, my only concern was py_object. I wondered whether the py_
prefix is really necessary, or, if it is meant to match PyObject*
whether it should be called PyObject or PyObject_p.

However, if every ctypes user knows what py_object is, there is
probably little point in renaming it.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64

[Thomas Heller]

Martin v. Löwis wrote:
> Thomas Heller wrote:
 return Py_BuildValue("s",
  ver.dwMajorVersion,
  ver.dwMinorVersion,
  ver.dwBuildNumber,
  ver.dwPlatformId,
  ver.szCSDVersion);

 The crash disappears if I change the first parameter in the
 Py_BuildValue call to "s".  No idea why.
 With this change, I can start the exe without a crash, but
 sys.versioninfo starts with (IIRC) (2, 0, 5,...).
>>> Very strange. What is your compiler version (first line of cl /?)?
> 
> I have looked into this. In the latest SDK (2003 SP1), Microsoft has
> changed the include structure; there are no separate amd64
> subdirectories anymore. Then, cl.exe was picking up the wrong
> stdarg.h (the one of VS 2003), which would not work for AMD64.
> 
> I have corrected that in vsextcomp, but I will need to check a few
> more things before releasing it.

I've upgraded to vsextcomp0.8.

On XP (32-bit), I can compile python25.dll and python.exe for AMD64 now,
after adding bufferoverflowU.lib to the linker options.
And the exe even works on XP-64 ;-)

When trying to build on XP64, I get errors like these (if it helps, I can 
upload the complete buildlogs
somewhere):

-- Rebuild All started: Project: make_buildinfo, Configuration: Release 
Win32 --

Deleting intermediate files and output files for project 'make_buildinfo', 
configuration 'Release|Win32'.
Compiling...
-- CL.EXE Wrapper for VSExtCompiler Plugin --
Error : Could not create new temporary options response file-- CL.EXE 
Wrapper for VSExtCompiler Plugin --
-- CL.EXE Wrapper for VSExtCompiler Plugin --
(lots of these lines removed)
-- CL.EXE Wrapper for VSExtCompiler Plugin --
Linking...
-- LINK.EXE Wrapper for VSExtCompiler Plugin --
Error : Could not create new temporary options response file-- LINK.EXE 
Wrapper for VSExtCompiler Plugin --
-- LINK.EXE Wrapper for VSExtCompiler Plugin --
(lots of these lines removed)
-- LINK.EXE Wrapper for VSExtCompiler Plugin --

Build log was saved at 
"file://c:\devel\trunk\PCbuild\x86-temp-release\make_buildinfo\BuildLog.htm"
make_buildinfo - 0 error(s), 0 warning(s)


-- Rebuild All started: Project: make_versioninfo, Configuration: Release 
Win32 --

Deleting intermediate files and output files for project 'make_versioninfo', 
configuration 'Release|Win32'.
Compiling...
-- CL.EXE Wrapper for VSExtCompiler Plugin --
Error : Could not create new temporary options response file-- CL.EXE 
Wrapper for VSExtCompiler Plugin --
-- CL.EXE Wrapper for VSExtCompiler Plugin --
(lots of these lines removed)
-- CL.EXE Wrapper for VSExtCompiler Plugin --
Linking...
-- LINK.EXE Wrapper for VSExtCompiler Plugin --
Error : Could not create new temporary options response file-- LINK.EXE 
Wrapper for VSExtCompiler Plugin --
-- LINK.EXE Wrapper for VSExtCompiler Plugin --
(lots of these lines removed)
-- LINK.EXE Wrapper for VSExtCompiler Plugin --
Performing Custom Build Step
'.\make_versioninfo.exe' is not recognized as an internal or external command,
operable program or batch file.
Project : error PRJ0019: A tool returned an error code from "Performing Custom 
Build Step"

Build log was saved at 
"file://c:\devel\trunk\PCbuild\x86-temp-release\make_versioninfo\BuildLog.htm"
make_versioninfo - 1 error(s), 0 warning(s)


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

Re: [Python-Dev] Visual studio 2005 express now free

[Martin v. Löwis]

Guido van Rossum wrote:
> Microsoft just announced that Visual Studio 2005 express will be free
> forever, including the IDE and the optimizing C++ compiler. (Not
> included in the "forever" clause are VS 2007 or later versions.)
> 
> Does this make a difference for Python development for Windows?

For future versions, perhaps. For 2.5, I think we now have settled
on VS 2003, for several reasons:
- I personally consider VS 2005 still verdant (crude? immature?
  unfledged?). They can't really mean the whole breakage they have
  done to the C library. Also, I expect another release of VS
  after Vista, to cover all the new .NET API, and I hope that
  we can skip VS 2005 (although Vista gets delays, and so gets
  VS 2007)
- Fredrik Lundh points out that it would be nice if people producing
  extensions for multiple Python releases wouldn't need a separate
  compiler for each release.
- Paul Moore has contributed a Python build procedure for the
  free version of the 2003 compiler. This one is without IDE,
  but still, it should allow people without a VS 2003 license
  to work on Python itself; it should also be possible to develop
  extensions with that compiler (although I haven't verified
  that distutils would pick that up correctly).

Regards,
Martin

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

Re: [Python-Dev] setuptools in 2.5.

[Phillip J. Eby]

At 12:51 PM 4/21/2006 -0400, Jim Jewett wrote:
>Phillip J. Eby wrote:
>
> > Such packages may have customized their installation process
> > by extending the distutils, *without* overriding get_outputs().  Since few
> > people actually use the --record option for anything important, nobody
> > notices when it breaks.
>
>I just searched through the (2.4.2) documentation, and could find no
>reference to either get_outputs or --record.  I also looked through
>the source, and couldn't find any reference to --record.  (I later
>found one in bdist_rpm, but "build a binary for Red Hat Linux" isn't a
>natural thing for anyone not on Linux to even try.)
>
>When I did a grep (which I wouldn't do unless I already knew I needed
>to worry about it), I finally found a few references in install.py
>which boiled down to "nothing happens, but you could get a list of
>files if you went through enough contortions".  This looks more like a
>debugging aid than something I would have to worry about.

As I said, this is probably why most actual system packaging tools use 
--root to record the results instead.  Of course, it's still possible for 
people to do extensions that break --root, so what it basically boils down 
to is that customizing the distutils is generally a bad idea -- except that 
for lots of things there seems to be no other choice.


> > As for --install-data, just put your data in the packages and use Python
> > 2.4's ability to install package data, or one of the pre-existing distutils
> > extensions that beat install_data over the head to make it install the data
> > with the packages.
>
>Use of a third-party extension (that isn't mentioned in the docs) is
>hardly intuitive.

Python 2.4 has the package_data option, and it is documented.  This feature 
was first implemented in setuptools, and then Fred Drake backported it to 
Python and wrote documentation for it.


>   If it is really required, that is far more
>intrusive than the stdlib changes setuptools makes.  (Would it only
>intrude on the packager, at least?  But then how could he or she be
>confident that the package would work on someone else's box?)

I'm not sure I follow you.  If you want to install data inside your package 
directories, and you don't have at least Python 2.4, you'll have to extend 
the distutils.  You can do it yourself (possibly borrowing code from 
another package that looks like it does what you want) or you can use 
setuptools; those are pretty much your only options.

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

Re: [Python-Dev] Visual studio 2005 express now free

[Giovanni Bajo]

Martin v. Löwis wrote:

> - Paul Moore has contributed a Python build procedure for the
>   free version of the 2003 compiler. This one is without IDE,
>   but still, it should allow people without a VS 2003 license
>   to work on Python itself; it should also be possible to develop
>   extensions with that compiler (although I haven't verified
>   that distutils would pick that up correctly).

It's been possible to compile distutils extensions with the VS 2003 toolkit
for far longer than it's possible to compile Python itself:
http://www.vrplumber.com/programming/mstoolkit/

In fact, it would be great if the patches provided here were reviewed and
integrated into the official Python distutils.
-- 
Giovanni Bajo

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

Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64

[Martin v. Löwis]

Thomas Heller wrote:
> On XP (32-bit), I can compile python25.dll and python.exe for AMD64 now,
> after adding bufferoverflowU.lib to the linker options.

On what project? There should be /GS- options on all projects that need
it, which, in turn, should result in bufferoverflowU.lib not being needed.

Or I forgot to check that change in... Will do Monday.

> Error : Could not create new temporary options response file

I've never seen these. I will have to study the source again, and
find out how that could happen.

Do you have spaces in the directory leading to the working copy?

Regards,
Martin

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

Re: [Python-Dev] Visual studio 2005 express now free

[Martin v. Löwis]

Giovanni Bajo wrote:
> It's been possible to compile distutils extensions with the VS 2003 toolkit
> for far longer than it's possible to compile Python itself:
> http://www.vrplumber.com/programming/mstoolkit/

Sure: with distutils modifications.

> In fact, it would be great if the patches provided here were reviewed and
> integrated into the official Python distutils.

Something like this should already be in Python 2.5. I just haven't
tested it in this configuration.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Tim Peters]

[Mateusz Rukowicz]
>> I wish to participate in Google Summer of Code as a python developer. I
>> have few ideas, what would be improved and added to python. Since these
>> changes and add-ons would be codded in C, and added to python-core
>> and/or as modules,I am not sure, if you are willing to agree with these
>> ideas.
>>
>> First of all, I think, it would be good idea to speed up long int
>> implementation in python. Especially multiplying and converting
>> radix-2^k to radix-10^l. It might be done, using much faster algorithms
>> than already used, and transparently improve efficiency of multiplying
>> and printing/reading big integers.

[Guido van Rossum]
> That would be a good project, if someone is available to mentor it.
> (Tim Peters?)

Generally speaking, I think longobject.c is already at the limit for
what's _reasonable_ for the core to support in C.  In fact, I regret
that we added Karatsuba multiplication.  That grossly complicated
CPython's bigint multiplication code, yet anyone slinging bigints
seriously would still be far better off using a Python wrapper for a
library (like GMP) seriously devoted to gonzo bigint algorithms.

CPython is missing mountains of possible bigint optimizations and
algorithms, and that's fine by me -- the core can't afford to keep up
with (or even approach) the state of the art for such stuff, but there
are already Python-callable libraries that do keep up.

Speeding the decimal module is a more attractive project.  Note that's
an explicit possibility for next month's "Need for Speed" sprint:

http://mail.python.org/pipermail/python-dev/2006-April/063428.html

Mateusz, if that interests you, it would be good to contact the sprint
organizers.

>> Next thing I would add is multi precision floating point type to the
>> core and fraction type, which in some cases highly improves operations,
>> which would have to be done using floating point instead.

You can have this today in Python by installing the GMP library and
its Python wrapper.

>> Of course, math module will need update to support multi precision
>> floating points, and with that, one could compute asin or any other
>> function provided with math with precision limited by memory and time.
>> It would be also good idea to add function which computes pi and exp
>> with unlimited precision.

I don't think the CPython core can afford to support such
sophisticated and limited-audience algorithms.  OTOH, the decimal type
has potentially unbounded precision already, and the math-module
functions have no idea what to do about that.  Perhaps some non-gonzo
(straightforward even if far from optimal, and coded in Python)
arbitrary-precision algorithms would make a decent addition.  For
example, the Emacs `calc` package uses non-heroic algorithms that are
fine for casual use.

> I would suggest doing this as a separate module first, rather than as
> a patch to the Python core.
>
> Can you show us some practical applications of these operations?

He could, yes, but they wouldn't meet any web developer's definition
of "practical".  The audience is specialized (he says as if web
developers' peculiar desires were universal ;-)).

>> And last thing - It would be nice to add some number-theory functions to
>> math module (or new one), like prime-tests,

GMP again, although the developers note:

http://www.swox.com/gmp/projects.html
...
GMP is not really a number theory library and probably shouldn't have
large amounts of code dedicated to sophisticated prime testing
algorithms, ...

If they think doing much more here is out of bounds for them, trying
to sneak it into longobject.c is crazy :-)  Note that tests like
Miller-Rabin are very easy to code in Python.

> factorizations etc.

Very large topic all by itself.  On Windows, I use factor.exe:

http://indigo.ie/~mscott/

and call it from Python via os.popen().  That doesn't implement the
Number Field Sieve, but does use most earlier high-powered methods
(including elliptic curve and MPQS).

> Probably better a new module. But how many people do you think need these?

The people who install GMP <0.5 wink>.

>> Every of above improvements would be coded in pure C, and without using
>> external libraries, so portability of python won't be cracked, and no
>> new dependencies will be added.

> Great -- that's important!

Since when does coding a module in pure C do anything for Jython or
IronPython or PyPy besides make their lives more difficult?  It would
be better to code in Python, if the functionality is all that's
desired; but it isn't, and getting gonzo speed too is the proper
concern of libraries and development teams devoted to gonzo-speed math
libraries.

>> I am waiting for your responses about my ideas, which of these you think
>> are good, which poor etc. Main reason I am posting my question here is
>> that, I am not sure, how much are you willing to change the core of the
>> python.

All the things you mentioned are Good Things, solving 

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Alex Martelli]

On 4/21/06, Mateusz Rukowicz <[EMAIL PROTECTED]> wrote:
   ...
> So I think the most valuable of my ideas would be improving long int +
> coding decimal in C. Anyway, I think it would be possible to add other
> ideas later.

I see "redo Decimal in C" (possibly with the addition of some fast
elementary transcendentals) and "enhance operations on longs"
(multiplication first and foremost, and base-conversions probably
next, as you suggested -- possibly with the addition of some fast
number-theoretical functions) as two separate projects, each of just
about the right magnitude for an SoC project. I would be glad to
mentor either (not both); my preference would be for the former -- it
appears to me that attempting to do both together might negatively
impact both.  Remember, it isn't just the coding...: thorough testing,
good docs, accurate performance measurements on a variety of
platforms, ..., are all important part of a project that, assuming
success, it's scheduled to become a core part of Python 2.6, after
all.


Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools in 2.5.

[Jim Jewett]

On 4/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:51 PM 4/21/2006 -0400, Jim Jewett wrote:
> >Phillip J. Eby wrote:

> > > As for --install-data
> > > ... one of the pre-existing distutils extensions ...

> > Use of a third-party extension (that isn't mentioned
> > in the docs [2.3]) is hardly intuitive.

> >   If it is really required, that is far more
> >intrusive than the stdlib changes setuptools makes.

> [Request for clarification]

If I were developing under 2.3, having to install a 3rd-party tool to
make distutils work is no better than installing setuptools, even with
its changes to the stdlib -- and considerably worse, since setuptools
is at least a blessed extension.

Even if I'm developing mostly with 2.5, I'm reluctant to require that
my users install more than they need to.  I don't like that setuptools
is needed, and changes their system defaults -- but that is still
better than doing the same thing with a random third-party extension.

-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Guido van Rossum]

Phillip, I do recomment you look at decimal.py. If we're not reversing
the PEP changes, that module needs to be changed; it has a class
Context (that was always there) with a __context__ method which
returns an instance of a class ContextManager (newly created for the
with-statement). This looks backwards from the PEP's current POV.

--Guido

On 4/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:51 AM 4/21/2006 -0400, A.M. Kuchling wrote:
> >On Fri, Apr 21, 2006 at 07:31:35PM +1000, Nick Coghlan wrote:
> > > fit the new definition. So we settled on calling them "context managers"
> > > instead.
> >  ...
> > > method. Instead, the new term "manageable context" (or simply "context")
> > > was introduced to mean "anything with a __context__ method". This was OK,
> >
> >Meaning that 'manageable context' objects create and destroy 'context
> >managers'...  My view is still that 'context manager' is a terrible
> >name when used alongside objects called 'contexts': the object doesn't
> >manage anything, and it certainly doesn't manage contexts -- in fact
> >it's created by 'context' objects.
>
> And that's more or less why I wrote the documentation the way I did.
>
> Nick, as I understand your argument, it's that we were previously using the
> term "context manager" to mean "thing with __enter__ and __exit__".  But
> that was *never* my interpretation.
>
> My understanding of "context manager" was always, "thing that you give to a
> with statement".
>
> So to me, when we added a __context__ method, we were creating a *new
> object* that hadn't existed before, and we moved some methods on to
> it.  Thus, "context manager" still meant "thing you give to the with
> statement" -- and that never changed, from my POV.
>
> And that's why I see the argument that we've "reversed" the terminology as
> bogus: to me it's been consistent all along.  We just added another object
> *besides* the context manager.
>
> Note too that the user of the "with" statement doesn't know that this other
> object exists, and in fact sometimes it doesn't actually exist, it's the
> same object.  None of this is relevant for the with-statement user, only
> the context manager.  So there's no reason (IMO) to monkey with the
> definition of "context manager" as "thing you use in a with statement".
>
> Now, I get your point about @contextmanager on a __context__ method, and I
> agree that that seems backwards at first.  What I don't see is how to
> change the terminology to handle that subtlety in a way that doesn't muck
> up the basically simple definitions that are in place now.
>
> If it must be explained, however, I'd rather simply document it in
> contextlib that @contextmanager-decorated functions return an object that
> is both a context manager and a context (or whatever name you want for the
> invisible-behind-the-scenes-thing with enter and exit methods).  Since it
> is possible for an object to be both, that seems to do fine for explaining
> why you can use @contextmanager to define a __context__ method.
>
> I'm definitely open to other terminology for the invisible thing besides
> "context", but I don't care for "managed context" or "manageable context",
> as these aren't much better.  I'm somewhat tempted by "context instance" or
> "context invocation".  E.g, the __context__ method should return a "context
> instance": an object representing a single instance of use of the
> context.  There's a wee hint of suggestion that this means "instance of
> type context", but it's more suggestive of one-time use than "context object".
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64

[Thomas Heller]

Martin v. Löwis wrote:
> Thomas Heller wrote:
>> On XP (32-bit), I can compile python25.dll and python.exe for AMD64 now,
>> after adding bufferoverflowU.lib to the linker options.
> 
> On what project? There should be /GS- options on all projects that need
> it, which, in turn, should result in bufferoverflowU.lib not being needed.
> 
> Or I forgot to check that change in... Will do Monday.

Ok, /GS- helps.  No need to hurry - I would commit that myself but I only
have readonly sandboxes on these installations, no putty, and so on.

>> Error : Could not create new temporary options response file
> 
> I've never seen these. I will have to study the source again, and
> find out how that could happen.
> 
> Do you have spaces in the directory leading to the working copy?

No.

But your guess is somewhat correct:  If I move the sandbox to a path *with* 
spaces
in it, this problem goes away ;-).  On the 64-bit box.

Now I have to learn how to debug on win64.

Thanks,

Thomas

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

Re: [Python-Dev] python 2.5alpha and naming schemes

[Thomas Heller]

Martin v. Löwis wrote:
> Thomas Heller wrote:
>> Personally, I *like* the ctypes name.  But I'm open for suggestions,
>> and it might have intersting consequences if the Python core package
>> would be renamed to something else.
>>
>> Any suggestions?
> 
> Well, my only concern was py_object. I wondered whether the py_
> prefix is really necessary, or, if it is meant to match PyObject*
> whether it should be called PyObject or PyObject_p.
> 
> However, if every ctypes user knows what py_object is, there is
> probably little point in renaming it.

I have learned that it is too late to rename things in ctypes.
If it were still possible, there would be a lot lot more to clean up, but
it has grown over the last three years or so.

Thomas

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

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Guido van Rossum]

On 4/21/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> OTOH, the decimal type
> has potentially unbounded precision already, and the math-module
> functions have no idea what to do about that.  Perhaps some non-gonzo
> (straightforward even if far from optimal, and coded in Python)
> arbitrary-precision algorithms would make a decent addition.  For
> example, the Emacs `calc` package uses non-heroic algorithms that are
> fine for casual use.

(Slightly off-topic.) I wonder if the math module would actually be a
good proving ground for generic/overloaded functions. It seems a clean
fit (and even has a few applications for multiple dispatch, probably).

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Visual studio 2005 express now free

[Paul Moore]

On 4/21/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> - Paul Moore has contributed a Python build procedure for the
>   free version of the 2003 compiler. This one is without IDE,
>   but still, it should allow people without a VS 2003 license
>   to work on Python itself; it should also be possible to develop
>   extensions with that compiler (although I haven't verified
>   that distutils would pick that up correctly).

It works fine. You need to set PATH, INCLUDE, and LIB appropriately,
and set MSSdk (to anything, but the SDK install location is what it's
meant to be) so that distutils assumes the environment is right and
doesn't check the registry.

I'll see if I can find some time to write a doc patch - it can go
alongside the "building using mingw" section.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64

[Thomas Heller]

Thomas Heller wrote:
> Martin v. Löwis wrote:
>> Thomas Heller wrote:
>>> On XP (32-bit), I can compile python25.dll and python.exe for AMD64 now,
>>> after adding bufferoverflowU.lib to the linker options.
>> On what project? There should be /GS- options on all projects that need
>> it, which, in turn, should result in bufferoverflowU.lib not being needed.
>>
>> Or I forgot to check that change in... Will do Monday.
> 
> Ok, /GS- helps.  No need to hurry - I would commit that myself but I only
> have readonly sandboxes on these installations, no putty, and so on.
> 
>>> Error : Could not create new temporary options response file
>> I've never seen these. I will have to study the source again, and
>> find out how that could happen.
>>
>> Do you have spaces in the directory leading to the working copy?
> 
> No.
> 
> But your guess is somewhat correct:  If I move the sandbox to a path *with* 
> spaces
> in it, this problem goes away ;-).  On the 64-bit box.

I forgot to mention that there are a lot of warnings about conversion betweem 
Py_ssize_t
to int - if you want me to fix the obvious ones I'll offer to correct some of 
them from time
to time and commit the changes.  I wonder why gcc doesn't warn about those.

Thomas

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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[A.M. Kuchling]

On Fri, Apr 21, 2006 at 06:54:11PM +0100, Guido van Rossum wrote:
> Phillip, I do recomment you look at decimal.py. If we're not reversing
> the PEP changes, that module needs to be changed; it has a class
> Context (that was always there) with a __context__ method which
> returns an instance of a class ContextManager (newly created for the
> with-statement). This looks backwards from the PEP's current POV.

Does this detail matter to users of the Decimal module, though?  Those
users may well be thinking using the term 'context'.  That the
underlying 'with' details use the term differently doesn't matter to
module users, only to the implementors of decimal.Context.

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Guido van Rossum]

On 4/21/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 21, 2006 at 06:54:11PM +0100, Guido van Rossum wrote:
> > Phillip, I do recomment you look at decimal.py. If we're not reversing
> > the PEP changes, that module needs to be changed; it has a class
> > Context (that was always there) with a __context__ method which
> > returns an instance of a class ContextManager (newly created for the
> > with-statement). This looks backwards from the PEP's current POV.
>
> Does this detail matter to users of the Decimal module, though?  Those
> users may well be thinking using the term 'context'.  That the
> underlying 'with' details use the term differently doesn't matter to
> module users, only to the implementors of decimal.Context.

Half and half. I'm not proposing to rename Context (which is already
well known). But ContextManager is brand new and uses the confused
terminology, so perhaps ought to be renamed to something else (and it
should probably get a leading underscore too, lest people start
instantiating it).

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Phillip J. Eby]

At 06:54 PM 4/21/2006 +0100, Guido van Rossum wrote:
>Phillip, I do recomment you look at decimal.py. If we're not reversing
>the PEP changes, that module needs to be changed; it has a class
>Context (that was always there) with a __context__ method which
>returns an instance of a class ContextManager (newly created for the
>with-statement). This looks backwards from the PEP's current POV.

I don't mind doing the work to change it, as long as you first pronounce on 
what the terminology *should* be.  :)  If it turns out my doc was wrong, 
I'll fix that.  If not, I'll fix decimal.ContextManager.  Or if both are 
wrong, I'll fix that too.  Just tell me which it is.  :)

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

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Josiah Carlson]

"Tim Peters" <[EMAIL PROTECTED]> wrote:
> [Mateusz Rukowicz]
> >> And last thing - It would be nice to add some number-theory functions to
> >> math module (or new one), like prime-tests,
> 
> If they think doing much more here is out of bounds for them, trying
> to sneak it into longobject.c is crazy :-)  Note that tests like
> Miller-Rabin are very easy to code in Python.

I've seen at least two examples of such in the ASPN Python cookbook.

 - Josiah

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

Re: [Python-Dev] Summer of Code preparation

[Facundo Batista]

2006/4/17, Neal Norwitz <[EMAIL PROTECTED]>:

> I can help manage the process from inside Google, but I need help
> gathering mentors and ideas.  I'm not certain of the process, but if
> you are interested in being a mentor, send me an email.  I will try to

I already applied to Google to be a Mentor. Hope I'll help with
spanish-talking students!

Regards,

.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] setuptools: past, present, future

[Phillip J. Eby]

I've noticed that there seems to be a lot of confusion out there about what 
setuptools is and/or does, at least among Python-Dev folks, so I thought it 
might be a good idea to give an overview of its structure, so that people 
have a better idea of what is and isn't "magic".

Setuptools began as a fairly routine collection of distutils extensions, to 
do the same boring things that everybody needs distutils extensions to 
do.  Basic stuff like installing data with your packages, running unit 
tests, that sort of thing.

At some point, I was getting tired of having to deal with dependencies by 
making people install them manually, or else having to bundle them.  I 
wanted a more automated way to deal with this problem, and in 2004 brought 
the problem to the distutils-sig and planned to do a PyCon sprint to try to 
address the problem.  Tim Peters encouraged me to move the preliminary work 
I'd done to the Python sandbox, where others could follow the work and 
improve upon it, and he sponsored me for CVS privileges so I could do so.

As it turned out, I wasn't able to go to PyCon, but I produced some crude 
stuff to try to implement dependency handling, based on some previous work 
by Bob Ippolito.  Bob's stuff used imports to check version strings, and 
mine was a bit more sophisticated in that it could scan .py or .pyc files 
without actually importing them.  But there was no reasonable way to track 
download URLs, though, or deal with the myriad package formats (source, 
RPM, etc.) platform-specificness, etc. and PyPI didn't really exist yet.

To top it all off, within a couple of months I was laid off, so the problem 
ceased to be of immediate practical interest for me any more.  I decided to 
take a six-month sabbatical and work on RuleDispatch, after which I began 
contracting for OSAF.

OSAF's Chandler application has a plugin platform akin to Eclipse, and I 
saw that it was going to need a cross-platform plugin format.  I put out 
the call to distutils-sig, and Bob Ippolito took up the challenge.  We 
designed the first egg format, and we agreed that it should support Python 
libraries, not just plugins, and that it should be possible to treat .egg 
zipfiles and directories interchangeably, and that it should be possible to 
put more than one conceptual egg into one physical zipfile.  The true "egg" 
was the project release, not the zipfile itself.  (We called a zipfile 
containing multiple eggs a "basket", which we thought would be useful for 
things like py2exe.  pkg_resources still supports baskets today, but there 
are no tools for generating them - you have to just zip up a bunch of .egg 
directories to make one.)

Bob wrote the prototype pkg_resources module to support accessing resources 
in zipfiles and regular directories, while I worked on creating a bdist_egg 
command, which I added to the then-dormant setuptools package, figuring 
that the experimental dependency stuff could be later refactored to allow 
dependencies to be resolved using eggs.  We had a general notion that there 
would be some kind of web pages you could use to list packages on, since at 
that time PyPI didn't allow uploads yet.  Or at any rate, we didn't know 
about it until PyCon in 2005.

After PyCon, I kept hearing about projects to make a CPAN-like tool for 
Python, such as the Uragas project.  However, all of these projects sounded 
like they were going to reinvent everything from scratch, particularly a 
lot of stuff that Bob and I had just done.  It then occurred to me for the 
first time that the .egg format could be used to solve the problems both of 
having a local package database, and also the uninstallation and upgrade of 
packages.  In fact, the only piece missing was that there was no way to 
find and download the packages to be installed, and if I could solve that 
problem, the CPAN problem would be solved.

So, I did some research by taking a random sample of packages from PyPI, to 
find out what information people were actually registering.  I found that, 
more often than not, at least one of their PyPI URLs would point to a page 
that had links to packages that could be downloaded directly.  And that was 
basically enough to permit writing a very simple spider that would only 
follow "download" or "homepage" links from PyPI pages, and would also 
inspect URLs to see if they were recognizable as distutils-generated 
filenames, from which it could extract package name and version info.

Thus, easy_install was born, completing what some people now call the 
eggs/setuptools/easy_install trifecta.

If you are going to work on or support these tools, it's important that you 
understand that these three things are related, but distinct.  Setuptools 
is at heart just an ordinary collection of distutils enhancements, that 
just happens to include a bdist_egg command.  EasyInstall is another 
enhanced command built on setuptools, that leverages setuptools to build 
eggs for packages that don't have them.  Bu

Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64

[Martin v. Löwis]

Thomas Heller wrote:
> I forgot to mention that there are a lot of warnings about conversion
> betweem Py_ssize_t to int - if you want me to fix the obvious ones
> I'll offer to correct some of them from time to time and commit the
> changes.

Right - they have been there ever since I started (in fact, I started
this entire project *because* of these warnings). You can get them on
x86, too, if you enable /Wp64.

Please feel free to fix any of them that you feel comfortable about.

> I wonder why gcc doesn't warn about those.

It just doesn't implement truncation warnings between variables
of differently-sized integer types. This (typically) isn't undefined
behaviour: the C standard mandates very well what should happen for
these truncations. Warning about any and all truncations would
lead to incredible noise.

/Wp64 *only* works because they restrict themselves to int64->int32
warnings (essentially).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Reject or update PEP 243?

[Phillip J. Eby]

I just noticed that the 2.5 What's New references PEP 243 in relation to 
the distutils' "upload" command, but in fact the upload command implements 
a different mechanism entirely.  About the only thing the PEP and 
implementation have in common is that they do a POST to python.org/pypi and 
have a protocol_version field of "1".  Nothing else is the same.

Perhaps someone who knows how the actual implementation works could rewrite 
the PEP, or write another one?

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

Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

[Phillip J. Eby]

At 06:43 PM 4/21/2006 +0200, Martin v. Löwis wrote:
>They might need to be available outside "Python". Two use cases:
>
>1. The application embeds an sqlite database. Even though it
>knows how to get at the data, it can't use it, because the
>sqlite3 library won't accept
>.../foo-1.0.egg/resources/the_data
>(or some such) as a database name, if foo-1.0.egg is a ZIP file.
>
>If the installed application was a set of files, that would work.
>
>2. The application embeds an SGML DTD (say, HTML). In order to
>perform validation, it invokes nsgmls on the host system.
>It cannot pass the SGML catalog to nsgmls (using the -C option)
>since you can't refer to DTD files inside ZIP files inside
>an SGML catalog.
>
>If this was a bunch of installed files, it would work.
>
>3. The application includes an SSL certificate. It can't pass it
>to socket.ssl, since OpenSSL expects a host system file name,
>not a fragment of a zip file.
>
>If this was installed as files, it would work.

In all of these cases, the applications could use 
pkg_resources.resource_filename(), which returns a true OS filename, even 
for files inside of .zip files.  Of course, it does this by extracting to a 
cache directory in such cases, and is only suitable for read-only 
access.  But it works fine for such cases as these.  Passing a resource 
directory name results in an operating system directory name being returned 
as well, with all the contents (recursively extracted) therein.

If the application is *not* in a zip file, then resource_filename() simply 
returns the obvious results by __file__ manipulation, so the author need 
not concern him or herself with this in code.  They just use 
resource_string() or resource_string() wherever possible, and resort to 
resource_filename() when working with tools such as the above, that cannot 
handle anything but files.

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

[Python-Dev] IronPython Performance

[Brent Fulgham]

A while ago (nearly two years) an interesting paper was published by Jim Hugunin
(http://www.python.org/pycon/dc2004/papers/9/) crowing about the significant
speed advantage observed in this interpreter running on top of Microsoft's .NET
VM stack.  I remember being surprised by these results, as Python has always
seemed fairly fast for an interpreted language.

I've been working on the Programming Language Shootout for a few years now, and
after growing tired of the repeated requests to include scores for IronPython I
finally added the implementation this week.

Comparison of IronPython (1.0 Beta 5) to Python 2.4.3 [1] and IronPython (1.0 
Beta 1)
to Python 2.4.2 [2] do not match the results reported in the 2004 paper.  In 
fact,
IronPython is consistenly 3 to 4 times slower (in some cases worse than that), 
and
seemed to suffer from recursion/stack limitations.

Since the shootout runs on a Debian Linux box, I was not able to use Microsoft's
CLR; instead, I was pleased to find that Mono successfully ran most of the
Shootout testing suite.  The 1.0 Beta 1 version of IronPython was built using 
the
compiler chain that ships with Mono 1.1.13.6; the 1.0 Beta 5 version is an 
'official' build
from the IronPython download site running on Mono 1.1.13.4.

I am aware of the following issues that might affect the results:
1)  Mono vs. Microsoft's CLR.
2)  Python 2.1 vs. Python 2.4
3)  Changes in IronPython over the last two years.

In addition, there is a small startup cost paid by IronPython since the 
py_compile
libraries were not present in the IronPython beta, preventing me from 
precompiling
the *.py files to *.pyo.  However, most of our benchmarks are now sufficiently 
long
that initial startup costs are less significant.

I thought these findings might be interesting to some of the Python, IronPython,
and Mono developers.  Let the flames begin!  ;-)

-Brent

===
Current results for Python versus IronPython are posted here:
[1] 
http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all〈=iron&lang2=python
[2] 
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all〈=iron&lang2=python






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

[Python-Dev] Easy, uncontroversial setuptools->distutils tasks

[Phillip J. Eby]

This is for the folks who wanted to get their feet wet with the setuptools 
codebase...

Setuptools has 4 "convenience" commands that can be trivially ported to the 
distutils, and 3 of those shouldn't require anything more than copying the 
code, translating the docs from reST to LaTeX, and changing a couple of 
imports from 'setuptools' to 'distutils'.

The four commands are: alias, rotate, saveopts and setopt.  Porting 'alias' 
will also require you to merge a few lines of alias expansion code from 
setuptools.dist.Distribution._parse_command_opts() into the corresponding 
class in distutils.dist, but the others should be entirely 
self-contained.  One of the commands also currently runs the "egg_info" 
command, but that's just to support setuptools' version-tagging features, 
which I'm not proposing be ported at the moment.

These aren't exactly critical features; they're really just conveniences 
for people that work with the distutils a lot.  Not really setuptools' main 
audience, in other words.  ;)  But getting these commands moved over in 2.5 
would take away a few hundred lines of code from setuptools and thereby 
make it about 5% less scary by line count, and about 15% less scary by 
module count.  :)

The reference documentation for these commands is in reST format in 
trunk/sandbox/setuptools.txt.  And speaking of the sandbox, if anybody 
wants to update setuptools.command.__init__ so it doesn't include these 
commands when running under 2.5, that counts for extra credit.  That is, it 
means you'll have worked on setuptools itself as well as the distutils.  :)

Any takers?  Better hurry, 'cause these modules *will* go fast.  :)  It'll 
probably take you longer to edit the docs than to change the code.

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

Re: [Python-Dev] setuptools in 2.5.

[Ian Bicking]

Paul Moore wrote:
> And no, I don't want to install the 2 versions side-by-side. Ian
> Bicking complained recently about the "uncertainty" of multiple
> directories on sys.path meaning you can't be sure which version of a
> module you get. Well, having 2 versions of a module installed and
> knowing that which one is in use depends on require calls which get
> issued at runtime worries me far more.

These are valid concerns.  From my own experience, I don't think 
setuptools makes it any worse than the status quo, but it certainly 
doesn't magically solve these issues.  And though these issues are 
intrinsically hard, I think Python makes it harder than it should.  For 
instance, if you really want to be confident about how your libraries 
are layed out, this script is the most reliable way: 
http://peak.telecommunity.com/dist/virtual-python.py

It basically copies all of Python to a new directory.  That this is 
required to get a self-consistent and well-encapsulated Python setup 
is... well, not good.  Maybe this could be fixed for Python 2.5 as well 
-- to at least make this isolation easier to apply.


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

Re: [Python-Dev] [Python-3000-checkins] r45617 - in python/branches/p3yk/Lib/plat-mac/lib-scriptpackages: CodeWarrior/CodeWarrior_suite.py CodeWarrior/__init__.py Explorer/__init__.py Finder/Container

[Greg Ewing]

Thomas Wouters wrote:
> 
> On 4/21/06, *guido.van.rossum*  > wrote:
> 
> somehow changing "import foo" into "from . import foo" ...
> caused things to break.  Bah. 
> 
> Hm, this is possibly a flaw in the explicit relative import mechanism. 

I don't see that this has anything to do with relative imports.
It's just the usual kind of problem you get with 'from ... import ...'
and mutual imports.

Does

import .foo

work?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Greg Ewing]

Alex Martelli wrote:

> GMP is covered by LGPL, so must any such derivative work

But the wrapper is just using GMP as a library, so
it shouldn't be infected with LGPLness, should it?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Alex Martelli]

On 4/21/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
   ...
> > GMP is covered by LGPL, so must any such derivative work
>
> But the wrapper is just using GMP as a library, so
> it shouldn't be infected with LGPLness, should it?

If a lawyer for the PSF can confidently assert that gmpy is not a
derivative work of GMP, I'll have no problem changing gmpy's
licensing. But I won't make such a call myself: for example, gmpy.c
#include's gmp.h and uses (==expands) some of the C macros there
defined -- doesn't that make gmpy.o a derived work of gmp.h?

I'm quite confident that the concept of "derived work" would not apply
if gmpy.so only accessed a gmp.so (or other kinds of dynamic
libraries), but I fear the connection is stronger than that, so,
prudently, I'm assuming the "derived work" status until further
notice.


Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [pypy-dev] Python Software Foundation seeksmentors and students for Google Summer of Code

[Terry Reedy]

"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> sign up through the Google SoC website!
> (code.google.com/soc/)

Easier said than done.  I emailed soc2006support suggesting that they add 
something or make whatever I missed more obvious.

tjr





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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Greg Ewing]

A.M. Kuchling wrote:

> Does this detail matter to users of the Decimal module, though?  Those
> users may well be thinking using the term 'context'.

Seems to me the most straightforward term should be
applied to the object that users are most likely to
know about and use. The term "context" is familiar
and understandable, whereas "context manager" isn't.

I've kind of lost track of why we're having two
separate objects, anyway. Is it really necessary?

As far as I remember, the original 'with' statement
proposal was very simple and quite straightforward
to explain and understand. Somewhere along the way
it seems to have mutated into a monster that I can't
keep in my brain any more. This can't be a good
thing.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] patch #1454481 - runtime tunable thread stack size

[Terry Reedy]

"Andrew MacIntyre" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> http://www.python.org/sf/1454481
>
> I would like to see this make it in to 2.5.  To that end I was hoping to
> elicit any review interest beyond Martin and Hye-Shik, both of whom I
> thank for their feedback.
>
> As I can't readily test on Windows (in particular) or Linux I would
> appreciate some kind soul(s) actually testing to make sure that the patch
> doesn't break builds on those platforms.

If you checked it in (after tests pass on your ?mac?, and while being ready 
to revert), wouldn't the next buildbot cycle do the testing you need? 
Isn't testing on 'other' platforms what buildbot is for?

tjr



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

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Bob Ippolito]

On Apr 21, 2006, at 5:58 PM, Alex Martelli wrote:

> On 4/21/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>...
>>> GMP is covered by LGPL, so must any such derivative work
>>
>> But the wrapper is just using GMP as a library, so
>> it shouldn't be infected with LGPLness, should it?
>
> If a lawyer for the PSF can confidently assert that gmpy is not a
> derivative work of GMP, I'll have no problem changing gmpy's
> licensing. But I won't make such a call myself: for example, gmpy.c
> #include's gmp.h and uses (==expands) some of the C macros there
> defined -- doesn't that make gmpy.o a derived work of gmp.h?
>
> I'm quite confident that the concept of "derived work" would not apply
> if gmpy.so only accessed a gmp.so (or other kinds of dynamic
> libraries), but I fear the connection is stronger than that, so,
> prudently, I'm assuming the "derived work" status until further
> notice.

Well we already wrap readline, would this really be any worse?   
Readline is GPL.

-bob

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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

Phillip J. Eby wrote:
> At 10:51 AM 4/21/2006 -0400, A.M. Kuchling wrote:
>> On Fri, Apr 21, 2006 at 07:31:35PM +1000, Nick Coghlan wrote:
>>> fit the new definition. So we settled on calling them "context managers"
>>> instead.
>>  ...
>>> method. Instead, the new term "manageable context" (or simply "context")
>>> was introduced to mean "anything with a __context__ method". This was OK,
>> Meaning that 'manageable context' objects create and destroy 'context
>> managers'...  My view is still that 'context manager' is a terrible
>> name when used alongside objects called 'contexts': the object doesn't
>> manage anything, and it certainly doesn't manage contexts -- in fact
>> it's created by 'context' objects.
> 
> And that's more or less why I wrote the documentation the way I did.
> 
> Nick, as I understand your argument, it's that we were previously using the 
> term "context manager" to mean "thing with __enter__ and __exit__".  But 
> that was *never* my interpretation.
> 
> My understanding of "context manager" was always, "thing that you give to a 
> with statement".

Then why didn't you speak up when the discussion was summarised in PEP 343 for 
Guido's approval? I said it explicitly:

  This PEP proposes that the protocol used by the with statement be
  known as the "context management protocol", and that objects that
  implement that protocol be known as "context managers". The term
  "context" then encompasses all objects with a __context__() method
  that returns a context manager object. (This means that all context
  managers are contexts, but not all contexts are context managers)

I guess a slight ambiguity came in from the fact I didn't spell out that the 
protocol I was referring to was all three methods with __context__ returning 
self (i.e. the moral equivalent of the 'iterator protocol'). But the rest of 
the paragraph doesn't make any sense otherwise.

Under Resolved Issues, before the recent changes, it said this:

  3. After this PEP was originally approved, a subsequent discussion
on python-dev [4] settled on the term "context manager" for
objects which provide __enter__ and __exit__ methods, and
"context management protocol" for the protocol itself. With the
addition of the __context__ method to the protocol, the natural
adjustment is to call all objects which provide a __context__
method "contexts" (or "manageable contexts" in situations where the
general term "context" would be ambiguous).
This is now documented in the "Standard Terminology" section.

*This* is what Guido approved, not what is currently written up in the PEP on 
python.org.

> So to me, when we added a __context__ method, we were creating a *new 
> object* that hadn't existed before, and we moved some methods on to 
> it.  Thus, "context manager" still meant "thing you give to the with 
> statement" -- and that never changed, from my POV.

That may have been what you personally thought, but it's not what the PEP 
said. If you disagreed with the summarisation in the PEP, you should have said 
so before Guido approved it, or brought it back to python-dev as a discussion 
about changing the standard terminology rather than just "the PEP's confusing, 
I want to clear it up" (and completely changing the meaning in the process).

> And that's why I see the argument that we've "reversed" the terminology as 
> bogus: to me it's been consistent all along.  We just added another object 
> *besides* the context manager.

I agree with the second part, but not the first part. Originally we only had 
context managers (objects that managed their own state in their 
__enter__/__exit__ methods). Jason brought up the point that this excluded 
decimal.Context objects because it was extremely difficult to produce a 
thread-safe and nesting-safe __enter__/__exit__ pair to manipulate the decimal 
context. Without a __context__ method, the decimal module would have had to 
provide a separate object for use as a context manager.

So we added contexts to the PEP - objects that could produce a context manager 
to work in conjunction with the with statement to manage the state of the 
context object. Context managers created in this fashion, instead of operating 
on their own state, actually operate on the state of the context that created 
them.

This is what got reversed in the contextlib docs - the PEP said that context 
managers work on contexts the same way that iterators work on iterables.The 
contextlib docs (and the latest version of the PEP) say that contexts 
manipulate context managers.

This is just plain bad English. "context" is a passive noun like "iterable" - 
it doesn't imply any sort of active operation. "context manager" on the other 
hand describes an actor doing something, just like "iterator" does.

> 
> Note too that the user of the "with" statement doesn't know that this other 
> object exists, and in fact sometimes it doesn't a

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

[Greg Ewing]

Alex Martelli wrote:
> gmpy.c
> #include's gmp.h and uses (==expands) some of the C macros there
> defined -- doesn't that make gmpy.o a derived work of gmp.h?

Assuming that gmp.h is the header which defines the
public interface of the gmp library, any code which
uses it as a library will be including gmp.h. So
that in itself doesn't imply that you're doing more
than using it as a library.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools: past, present, future

[Terry Reedy]

"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

I have some general comments which I will not try to tie to specific 
quotes.

1. Based on comments on c.l.py, the biggest legitimate fact-based (versus 
personal-taste-based) knock again Python versus, in particular, Perl is the 
lack of a CPAN-like facility.  As I remember, there have even been a few 
people say something like "I like Python the language better that Perl, but 
I won't switch because I love CPAN even more."  So I think easier code 
reuse will boost Python usage.

2. Some think that PEPs are not needed once Guido approves something, on 
the view that the main purpose of a PEP is to host a discussion to help him 
decide.  But I think you would have slept better if you had written a short 
PEP explaining the meaning of 'possible addition' and the implication of 
actual addition.

Regardless of the past, I think you should soon (when rested ;-) condense 
this down to a PEP 'Upgrading Disutils with Setuptools'.  Make separate 
sections for 2.5 upgrades and 2.6 plans.  Include the 'uncontroversial 
tasks' from your later post.  Reference this and a few other relevant 
posts.

3. I think must of the hostility expressed at setuptools really ought to be 
directed at the multiplicity of x86 *nix distribution formats, which I 
believe significantly inhibits the market for non-Windows systems.

History: I started microcomputing with a Z80 CP/M machine that, like 
others, had one of numerous vendor-specific, slightly incompatible, 
technically unneeded, user-contemptuous, 5-1/4 floppy formats.  So 3rd 
party software distribution was difficult (crippled), --  and all those 
vendors eventually died.

A few years later my employer got a desktop Motorola 68000 Unix system 
mostly to run a specific package.  It was a wonderful system, in some 
respects a couple of decades ahead of DOS and later Windows.  But the 
vendors copied the CP/M  mistake, making third-party software distribution 
across multiple systems non-existent  -- and as far as I know, they all 
died.

So I think a write-one-setup, distribute-everywhere system would be great.

4. Why can't you remove the heuristic and screen-scrape info-search code 
from the easy_install client and run one spider that would check 
new/revised PyPI entries, search for missing info, insert it into PyPI when 
found (and mark the entry eggified), or email the package author or a human 
search volunteer if it does not find enough?

Terry Jan Reedy



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

Re: [Python-Dev] setuptools: past, present, future

[Giovanni Bajo]

Phillip J. Eby <[EMAIL PROTECTED]> wrote:

> What *should* happen now instead, is a plan for merging setuptools
> into the distutils for 2.6.  That includes making the decisions about
> what "install" and "sdist" should do, and whether backward
> compatibility of internal behaviors should be implicit or explicit.

+1.

> Between 2.5 and 2.6, setuptools should continue to be developed in the
> sandbox, and keep the name 'setuptools'.  For 2.6, however, we should
> merge
> the code bases and have setuptools just be an alias.  Or, perhaps
> what is
> now called setuptools should be called "distutils2" and distributed as
> such, with "setuptools" only being a legacy name.  But regardless,
> the plan
> should be to have only one codebase for 2.6, and to issue backported
> releases of that codebase for at least Python 2.4 and 2.5.

+1.

> One final item that is a possibility: we could leave pkg_resources in
> for 2.5, and add its documentation.  This would allow people to begin
> using its API to check for installed packages, accessing resources, etc.
> I'd be interested in hearing folks' opinions about that, one way or the
> other.


This would be good. I believe pkg_resources is useful in 2.5 and in no way it
represents a not properly integrated layer of additional functionalities (like
setuptools is to distutils now). If you sincerely believe that pkg_resources'
API is mature enough, I don't see any reason for keeping it off 2.5.

Thanks for your hard work!

Giovanni Bajo

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

Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64

[Neal Norwitz]

On 4/21/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Thomas Heller wrote:
> > I forgot to mention that there are a lot of warnings about conversion
> > betweem Py_ssize_t to int - if you want me to fix the obvious ones
> > I'll offer to correct some of them from time to time and commit the
> > changes.
>
> Right - they have been there ever since I started (in fact, I started
> this entire project *because* of these warnings). You can get them on
> x86, too, if you enable /Wp64.

In case it wasn't clear, the /Wp64 flag is available in icc (Intel's C
compiler).

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Phillip J. Eby]

At 01:34 PM 4/22/2006 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
>>At 10:51 AM 4/21/2006 -0400, A.M. Kuchling wrote:
>>>On Fri, Apr 21, 2006 at 07:31:35PM +1000, Nick Coghlan wrote:
fit the new definition. So we settled on calling them "context managers"
instead.
>>>  ...
method. Instead, the new term "manageable context" (or simply "context")
was introduced to mean "anything with a __context__ method". This was OK,
>>>Meaning that 'manageable context' objects create and destroy 'context
>>>managers'...  My view is still that 'context manager' is a terrible
>>>name when used alongside objects called 'contexts': the object doesn't
>>>manage anything, and it certainly doesn't manage contexts -- in fact
>>>it's created by 'context' objects.
>>And that's more or less why I wrote the documentation the way I did.
>>Nick, as I understand your argument, it's that we were previously using 
>>the term "context manager" to mean "thing with __enter__ and 
>>__exit__".  But that was *never* my interpretation.
>>My understanding of "context manager" was always, "thing that you give to 
>>a with statement".
>
>Then why didn't you speak up when the discussion was summarised in PEP 343 
>for Guido's approval? I said it explicitly:
>
>  This PEP proposes that the protocol used by the with statement be
>  known as the "context management protocol", and that objects that
>  implement that protocol be known as "context managers". The term
>  "context" then encompasses all objects with a __context__() method
>  that returns a context manager object. (This means that all context
>  managers are contexts, but not all contexts are context managers)
>
>I guess a slight ambiguity came in from the fact I didn't spell out that 
>the protocol I was referring to was all three methods with __context__ 
>returning self (i.e. the moral equivalent of the 'iterator protocol'). But 
>the rest of the paragraph doesn't make any sense otherwise.

Because the last time I looked at the PEP, I was trying to make sure that 
the code samples in the PEP worked with Guido's last-minute decision to go 
with the return vs. raise protocol that I originally proposed for __exit__, 
and didn't have the time to sort through the terminology change.

Later, when I wrote up documentation, I mostly did it from memory.  The 
next time I looked at the PEP was when AMK asked for clarification.


>That may have been what you personally thought, but it's not what the PEP 
>said. If you disagreed with the summarisation in the PEP, you should have 
>said so before Guido approved it, or brought it back to python-dev as a 
>discussion about changing the standard terminology rather than just "the 
>PEP's confusing, I want to clear it up" (and completely changing the 
>meaning in the process).

I changed the PEP because Guido asked me to, right here on Python-Dev, 
after AMK asked the question and I seconded his guess as to the 
interpretation.  I wouldn't have otherwise checked in changes to a PEP that 
doesn't have my name on it:

http://mail.python.org/pipermail/python-dev/2006-April/063856.html

If you have a problem with what I did to the PEP, kindly take it up with 
Guido.  If you have a problem with the documentation I took the time to 
write and contribute, by all means change it.  At this point, I'm getting 
pretty tired of people of accusing me of violating procedures around here, 
and I'm past caring what you do or don't call the bloody objects.  At least 
I've gotten contextlib and test_contextlib to actually work, and arranged 
for there to be *some* documentation for the "with" statement and the 
contextlib module.

Meanwhile, the iterator-iterable analogy is false.  You have to be able to 
iterate over an iterator, but as AMK pointed out, you don't have to be able 
to pass a [thing having __enter__/__exit__] to a "with" statement.  So I 
was wrong to apply that analogy myself, as are you now.

That having been said, I don't think either you or I or even Guido should 
be the ones to fix the PEP and the docs at this point, as we've all stared 
at the bloody thing way too long to see it with fresh eyes.  So far, AMK is 
the one who's finding all our screwups, so maybe he should be the one to 
explain it all to *us*.  :)

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

Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64

[Martin v. Löwis]

Neal Norwitz wrote:
>> Right - they have been there ever since I started (in fact, I started
>> this entire project *because* of these warnings). You can get them on
>> x86, too, if you enable /Wp64.
> 
> In case it wasn't clear, the /Wp64 flag is available in icc (Intel's C
> compiler).

It still isn't clear :-) The flags is also available in msvc:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/vchowWp64Detect64BitPortabilityProblems.asp

There is even a checkbox for it in the project settings.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64

[Neal Norwitz]

On 4/21/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> >> Right - they have been there ever since I started (in fact, I started
> >> this entire project *because* of these warnings). You can get them on
> >> x86, too, if you enable /Wp64.
> >
> > In case it wasn't clear, the /Wp64 flag is available in icc (Intel's C
> > compiler).
>
> It still isn't clear :-) The flags is also available in msvc:

Glad to see there's still some humour left on py-dev.

I didn't say /Wp64 was *only* available in icc.   For anyone who
thinks I implied msvc, I've got a bridge for sale, just let me know.
:-)

Cheers,
n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Phillip J. Eby]

At 01:34 PM 4/22/2006 +1000, Nick Coghlan wrote:
>Then why didn't you speak up when the discussion was summarised in PEP 343 
>for
>Guido's approval? I said it explicitly:
>...
>That may have been what you personally thought, but it's not what the PEP
>said.

By the way, Greg Ewing coined the term "context manager", combining my 
proposals of "resource manager" and "context listener":

http://mail.python.org/pipermail/python-dev/2005-July/054607.html
http://mail.python.org/pipermail/python-dev/2005-July/054628.html

And from this email, it's clear that other people in the discussion 
interpreted this term to refer to "thing given to the 'with' statement":

http://mail.python.org/pipermail/python-dev/2005-July/054615.html

However, you seemed to want to call this a "context", even then:

http://mail.python.org/pipermail/python-dev/2005-July/054656.html

So, if anything is clear from all this, it's that nothing has ever been 
particularly clear in all this.  :)

Or more precisely, I think everybody has been perfectly clear, we just 
haven't really gotten on the same page about which words mean what.  ;)

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

Re: [Python-Dev] setuptools: past, present, future

[Phillip J. Eby]

At 12:22 AM 4/22/2006 -0400, Terry Reedy wrote:
>Why can't you remove the heuristic and screen-scrape info-search code
>from the easy_install client and run one spider that would check
>new/revised PyPI entries, search for missing info, insert it into PyPI when
>found (and mark the entry eggified), or email the package author or a human
>search volunteer if it does not find enough?

I actually considered that at one point.  After all, I certainly have the 
technology.

However, I didn't consider it for more than 10 seconds or so.  Package 
authors have no reason to listen to some random guy with a bot -- but they 
do have reasons to listen to their users, both actual and potential.

The problem isn't fundamentally a technical one, but a social one.  You can 
effect social change through technology, but not by being some random guy 
with a nagging 'bot.

Hm, can I nominate myself for the QOTF?  :)

Seriously, though, posting Cheesecake scores (which include ratings for 
findability of code, use of distutils, etc.) would be a fine way to achieve 
the same effect, and if they're part of PyPI itself, they don't give off 
the same "random guy with a bot" effect.  Instead, they are a visible 
reflection of community standards or values, and influence action through 
public shame instead of nagging.  And shame scales better as the size of a 
community increases.  :)

There are actually additional technical and social reasons why I don't 
believe the bot approach would work or scale well, even if it was clearly a 
community effort.  For example, doing the work *for* package authors would 
effectively mean supporting them forever, since they would never have a 
reason to learn to do it themselves.  But these other reasons rather pale 
compared to the chicken-and-egg problem that I'd have faced in trying to 
kick off such an effort without easy_install already having been 
established with a sizable base of fan(atic)s.

Anyway, it's certainly an attractive idea, and until you brought it up I'd 
forgotten I had even considered it once.  It would be nice if it could 
work, but I still think adding Cheesecake scores to PyPI would be a better 
accelerant -- especially because it measures other "qwalitee" factors 
besides easy_install-ability.

And since Cheesecake actually *depends* on easy_install to be able to rate 
documentation and various other aspects of a package (because it actually 
uses easy_install to find and fetch a package's source code), you're not 
going to be able to score at *all* on some factors if you don't make your 
package findable.  Thus, easy_install-ability is a prerequisite to even 
being able to see how you compare to others.

So... let them eat Cheesecake.  :)

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