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.
snip
People interested in mentoring a student though PSF are encouraged to
contact me, Neal Norwitz
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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*
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
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
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
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,
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
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
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,
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 wherefoo and bar import each other AND both are imported from __init__.py caused things to break.Bah.
Hm, this is possibly
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
On 4/21/06, Thomas Wouters [EMAIL PROTECTED] 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
On 4/21/06, Thomas Wouters [EMAIL PROTECTED] 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
At 06:26 PM 4/21/2006 +0200, Thomas Wouters wrote:
On 4/21/06, guido.van.rossum
mailto:python-3000-checkins@python.orgpython-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
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
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
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
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
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
Martin v. Löwis wrote:
Thomas Heller wrote:
return Py_BuildValue(s,
ver.dwMajorVersion,
ver.dwMinorVersion,
ver.dwBuildNumber,
ver.dwPlatformId,
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
Thomas Wouters wrote:
On 4/21/06, *guido.van.rossum* python-3000-checkins@python.org
mailto:python-3000-checkins@python.org 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
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
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
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
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
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
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
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
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
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.
77 matches
Mail list logo
