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

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),

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

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

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

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, t

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

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

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

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.

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

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 >

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

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 implic

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

"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, P

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

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 inclu

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

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 sim

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

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 lawye

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

"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

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

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 fa

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

"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 ___

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

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 deriva

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

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.

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 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

Re: [Python-Dev] setuptools in 2.5.

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

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

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 changi

[Python-Dev] IronPython Performance

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 Py

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

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.eg

[Python-Dev] Reject or update PEP 243?

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

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

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 f

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

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

Re: [Python-Dev] Summer of Code preparation

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 Ment

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

"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 c

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

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 ContextMana

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

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

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

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

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

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

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

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 po

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

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-precisi

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

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 won

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

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 bu

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

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 ba

Re: [Python-Dev] setuptools in 2.5.

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

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

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 element

Re: [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 ag

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

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 provid

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

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 neede

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

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

Re: [Python-Dev] setuptools in 2.5.

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 > > noti

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

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?

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

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

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

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 r

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

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 intr

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

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 a

[Python-Dev] setuptools in 2.5.

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, thoug

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

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 res

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

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

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

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 > ca

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

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 > ca

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

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 b

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

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 p

Re: [Python-Dev] windows buildbot failures

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). regard

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

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'

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

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 instea

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

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

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

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 s

Re: [Python-Dev] Distutils thoughts

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] patch #1454481 - runtime tunable thread stack size

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(

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

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 disappointi

Re: [Python-Dev] Distutils thoughts

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

Re: [Python-Dev] setuptools in 2.5.

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 l

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

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 de

Re: [Python-Dev] Distutils thoughts

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 --compil

Re: [Python-Dev] setuptools in 2.5.

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 i

Re: [Python-Dev] setuptools in 2.5.

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

Re: [Python-Dev] setuptools in 2.5.

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

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

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 PROT

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

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 ca

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

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

Re: [Python-Dev] Distutils thoughts

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

Re: [Python-Dev] windows buildbot failures

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

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

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 c

Re: [Python-Dev] setuptools in 2.5.

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

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

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 th

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

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 differe

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

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 c

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

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"

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

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 th

[Python-Dev] Visual studio 2005 express now free

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

Re: [Python-Dev] bin codec + EOF

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.pyth

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

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 t

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

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 n

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

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 a

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

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, Go

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

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 provid

Re: [Python-Dev] proposal: evaluated string

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 str

Re: [Python-Dev] Distutils thoughts

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 "insta

[Python-Dev] bin codec + EOF

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">>> "0111011000100110001

Re: [Python-Dev] Raising objections

"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 PendingDepr

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

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

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

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 tha

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

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 Norwi