Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
>> I don't understand it.
>
> Have you read the manuals?
You mean,
http://peak.telecommunity.com/DevCenter/setuptools
Yes, I did. However, this would only enable me to use it (should I
ever find a need). What I really need to understand is how all this
stuff works inside.
Now, I haven't actually *tried* to learn it so far. Fredrik's question
was not "who thinks he could learn it" (I certainly could), I
read his question as "who does understand it, as of today". I can't
faithfully answer "yes" to that question.
So far, I believe nobody has said "yes, I do understand it, and could
maintain it if Phillip Eby became unavailable".
> Please define "magic".
"Functionality with no obvious implementation, or functionality
implemented in an unobvious way".
> Better, please point to the API functions or
> classes, or the setup commands documented in the manual, to show me what
> these things are that appear to be magic.
Here are some that I either already knew, or discovered just now:
1. setuptools manages to replace pydoc on earlier Python versions.
MAL assumed it does so by overwriting the files. This would be
bad practice, but is the obvious solution.
You then told him that this is not what actually happens (so
it's already magic); instead, you arrange that Python finds
your version before it finds its own.
Again, this is still magic: How does it do that? If you append
to sys.path, Python would still find its own version before
it finds yours. So perhaps you insert another path at
sys.path[0]? This would also be bad practice, but it would
be the next-obvious approach.
But I fully expect that you are now telling me that this is
still not how it works.
2. setuptools manages to install code deep inside a subdirectory
of site-python, and manages to install multiple versions
simultaneously.
How does that work? The first part (packages outside sys.path)
can be solved with a .pth file (which I already consider bad
practice, as it predates the package concept of Python);
but that can't work for multiple versions: magic.
I (think I) know the answer: there is a single .pth file,
and that is *edited* on package installation time. This
is a completely non-obvious approach. If Python needs
to support multiple versions of a package (and there
is apparently a need), that should be supported
"properly", with a clear design, in a PEP.
3. namespace packages. From the documentation, I see that
you pass namespace_packages= to setup, and that you
put
__import__('pkg_resources').declare_namespace(__name__)
into the namespace package. How does that work?
The documentation only says
"This code ensures that the namespace package machinery
is operating and that the current package is registered
as a namespace package."
Also, why not
import pkg_resources
pkg_resources.declare_namespace(__name__)
What does declare_namespace actually do?
4. zip_safe. Documentation says
"If this argument is not supplied, the bdist_egg command
will have to analyze all of your project's contents
for possible problems each time it buids an egg."
How? Sounds like it is solving the halting problem, if
it manages to find possible problems.
> There do exist implementation details that are not included in user
> documentation, but this is going to be true of any system. These details
> are sometimes necessarily complex due to distutils limitations, behavioral
> quirks of deployed packages using distutils, and the sometimes baroque
> variations in sys.path resolution across platforms, Python versions, and
> invocation methods.
I trust that there is a good reason for each of them. However,
for inclusion in the standard library, some of these should go away:
- if you have distutils limitations, remove them
- differences in Python versions shouldn't matter: you always
know what the Python version is
- if there are baroque variations in sys.path resolution across
platforms, they should be removed, or modernized.
Not sure what "invocation methods" are.
>> This magic might do the "right thing" in many cases, and it might
>> indeed help the user that the magic is present, yet I still do believe
>> that magic is inherently evil: explicit is better than implicit.
>
> Are documented defaults "implicit" or "magic"?
Documented defaults are explicit.
> With respect to you and MAL, I think that some of your judgments regarding
> setuptools may have perhaps been largely formed at a time last year when,
> among other things:
>
> * That documentation section I just referenced didn't exist yet
I don't think I ever complained about the lack of documentation. I would
(personally) not trust the documentation, anyway, but always look at the
code to find out how it actually works. I read documentation primarily
to find out what the *intent* was.
> These are significant changes that are directly relevant to the objections
>
Re: [Python-Dev] New-style icons, .desktop file
Andrew Clover wrote: > Morning! > > I've done some tweaks to the previously-posted-about icon set, taking > note of some of the comments here and on -list. you do wonderful stuff, and then you post the announcement as a followup to a really old message, to make sure that people using a threaded reader only stumbles upon this by accident... this should be on the python.org frontpage! > included PNG and SVG version of icons. The SVG unfortunately doesn't > preserve all the effects of the original Xara files, partly because > a few effects (feathering, bevels) can't be done in SVG 1.1, and > partly because the current conversion process is bobbins (but we're > working on that!). So the nice gradients and things are gone, but it > should still be of use as a base for anyone wanting to hack on the > icons. hack SVG? what am I waiting for ? > Files and preview here: > >http://doxdesk.com/img/software/py/icons2.zip >http://doxdesk.com/img/software/py/icons2.png brilliant! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python Software Foundation seeks mentors and students for Google Summer of Code
This spring and summer, Google will again provide stipends for students (18+, undergraduate thru PhD programs) to write new open-source code. The Python Software Foundation (PSF) http://www.python.org/psf/ will again act as a sponsoring organization in Google's Summer of Code, matching mentors and projects benefiting Python and Python users. Projects can include work on the core Python language, programmer utilities, libraries, packages, frameworks related to Python, or other Python implementations like Jython, PyPy, or IronPython. Please add your project ideas to the existing set at http://wiki.python.org/moin/SummerOfCode Mentoring instructions are also on this page. The deadline is soon, so please sign up as a mentor early. If you are a student considering a project, you should start deciding now. Feel free to ask questions on [email protected] The main page for the Summer of Code is http://code.google.com/summerofcode.html At the bottom are links to StudentFAQ, MentorFAQ, and TermsOfService. The first two have the timeline. Note that student applications are due between May 1, 17:00 PST and May 8, 17:00 PST. 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. Feel free to contact me if you have any questions. I look forward to meeting many new mentors and students. Let's improve Python! Cheers, n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
Anthony Baxter wrote: > Not without a lot of the other stuff that's in setuptools. > >> That is says from itself that it is version 0.7a1dev-r45536 >> doesn't help to reduce that fear. > > It's had _two_ _years_ of quite active development, so the version > number of 0.7 is hardly a good indication. As far as all the other > stuff on the end of the version string - well, right now Python's SVN > trunk really could be considered 2.5a2dev-r45575. Right - I'm not concerned about the "a1dev-r45536" part. The 0.7 part bothers me; this is two years of development from a single person, still. I have projects that are much older than that that I wouldn't suggest for inclusion in Python :-) >> Requiring Phillip to rewrite distutils instead is certainly >> unfair - but I'm still unhappy with the path events take. > > He's written code on _top_ _of_ _distutils_. How is this bad? It makes distutils an implementation detail of setuptools. What little development distutils has seen will stop; all fixes will go into setuptools directly. Users will be told that they should switch to setuptools. Please face it: setuptools *is* the death of distutils. This might not be that bad in the long run, but it does have the risk of repeating, when setuptools eventually is where distutils is today: complete, and unmaintained. > See, I don't get the hostility thing. While I have some concerns about > the state of distutils today, I still admire Greg Ward's efforts in > producing the code, and Python is in a much better place than had he > not done the work. Responding to an effort like Greg's, or Phillip's, > with hostility is a fantastic way to discourage people from working > further on Python or on the code in question. Well, I appreciate other contributions from other people, and I have always encouraged people to contribute to Python. It's just that I dislike this *specific* package, for several reasons, some of which I consider objective. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New-style icons, .desktop file
Fredrik Lundh wrote: > you do wonderful stuff, and then you post the announcement as a > followup to a really old message, to make sure that people using a > threaded reader only stumbles upon this by accident... this should > be on the python.org frontpage! I also wonder what the actions should be for the Windows release. Are these "contributed" to Python? With work of art, I'm particular cautious to include them without a specific permission of the artist, and licensing terms under which to use them. And then, technically: I assume The non-vista versions should be included the subversion repository, and the vista versions ignored? Or how else should that work? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
On Thursday 20 April 2006 17:51, Martin v. Löwis wrote: > > He's written code on _top_ _of_ _distutils_. How is this bad? > > It makes distutils an implementation detail of setuptools. What > little development distutils has seen will stop; all fixes will > go into setuptools directly. Users will be told that they should > switch to setuptools. > Please face it: setuptools *is* the death of distutils. > This might not be that bad in the long run, but it does have > the risk of repeating, when setuptools eventually is where > distutils is today: complete, and unmaintained. I don't see why you assume it will be unmaintained. I plan to spend some time in the near future wrapping my brain around the code - heck, I was going to do it today, but spent time writing emails instead. :-) I also don't think it will be the "death" of distutils. I think that over time the two pieces of code will become closer together - hopefully for Python 3.0 we can formally merge the two. Augmenting or layering a more sophisticated piece of code over the top of the more simple code means that we can do more things, hopefully easier. And as people do more things, we will find the need to fix the bugs in the underlying code. > Well, I appreciate other contributions from other people, and I > have always encouraged people to contribute to Python. It's just > that I dislike this *specific* package, for several reasons, some > of which I consider objective. And you posed a number of concrete questions to PJE in the previous message, which is good - these are also some of the questions I had (but hadn't had the time to investigate yet). Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising objections
Phillip J. Eby wrote: > How much any of that could have also applied to the distutils at one > time, I don't know. My point is merely that setuptools has enough > commercial value to make me believe that sponsorship for features > shouldn't be that hard to come by, and there are certainly worse things > I could do with my work days. I'm glad to hear that you seem to be finding support for ongoing work on setuptools (I'm *really* glad to hear that; it's always good when people get funded to work on open source). I'm also happy to hear that Neal wants to study the complete source base of setuptools. Perhaps that means I won't have to :-) Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] valgrind reports
Neal Norwitz wrote: > This was run on linux amd64. It would be great to run purify on > windows and other platforms. If you do, please report back here, even > if nothing was found. That would be a good data point. > > Summary of tests with problems: > > test_codecencodings_jp (1 invalid read) > test_coding (1 invalid read) > test_ctypes (crashes valgrind) > test_socket_ssl (many invalid reads) > test_sqlite (1 invalid read, 1 memory leak) I've tried to run python under valgrind on linux x86 (Ubuntu 5.10). Here's what I get - python was configured with '--without-pymalloc --with-pydebug' after uncommenting the Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c. Is there something missing in the suppressions file? Thanks, Thomas [EMAIL PROTECTED]:~/devel/trunk$ valgrind --suppressions=Misc/valgrind-python.supp ./python -c "" ==13632== Memcheck, a memory error detector. ==13632== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==13632== Using LibVEX rev 1367, a library for dynamic binary translation. ==13632== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==13632== Using valgrind-3.0.1, a dynamic binary instrumentation framework. ==13632== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==13632== For more details, rerun with: -v ==13632== ==13632== Conditional jump or move depends on uninitialised value(s) ==13632==at 0x1B8F40FD: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E9DBA: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E484D: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8EE875: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E491C: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E7421: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8F1A6D: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E4D0E: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E47C6: (within /lib/ld-2.3.5.so) ==13632== ==13632== Conditional jump or move depends on uninitialised value(s) ==13632==at 0x1B8F410C: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E9DBA: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E484D: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8EE875: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E491C: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E7421: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8F1A6D: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E4D0E: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E47C6: (within /lib/ld-2.3.5.so) ==13632== ==13632== Conditional jump or move depends on uninitialised value(s) ==13632==at 0x1B8F411B: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E9DBA: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E484D: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8EE875: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E491C: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E7421: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8F1A6D: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E4D0E: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E47C6: (within /lib/ld-2.3.5.so) ==13632== ==13632== Conditional jump or move depends on uninitialised value(s) ==13632==at 0x1B8F4126: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E9DBA: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E484D: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8EE875: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E491C: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E7421: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8F1A6D: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E4D0E: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E47C6: (within /lib/ld-2.3.5.so) ==13632== ==13632== Conditional jump or move depends on uninitialised value(s) ==13632==at 0x1B8F4263: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E9DBA: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E484D: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8EE875: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E491C: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E7421: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8F1A6D: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E4D0E: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E47C6: (within /lib/ld-2.3.5.so) ==13632== ==13632== Conditional jump or move depends on uninitialised value(s) ==13632==at 0x1B8F426E: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E9DBA: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E484D: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8EE875: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E491C: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E7421: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8F1A6D: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E4D0E: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E47C6: (within /lib/ld-2.3.5.so) ==13632== ==13632== Conditional jump or move depends on uninitialised value(s) ==13632==at 0x1B8F4263: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E856C: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E9E33: (within /lib/ld-2.3.5.so) ==13632==by 0x1B8E484D: (within /lib/ld-2.3.5.so) ==13632==b
Re: [Python-Dev] setuptools in 2.5.
Anthony Baxter wrote: > I also don't think it will be the "death" of distutils. I think that > over time the two pieces of code will become closer together - > hopefully for Python 3.0 we can formally merge the two. I was hoping that for Python 3.0, we could get around to unkludge the sys.path/meta_path/path_hooks/path_importer_cache big ball of hacks, possibly by replacing sys.path with something a bit more intelligent than a plain list. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
Fredrik Lundh wrote: > Anthony Baxter wrote: > >> I also don't think it will be the "death" of distutils. I think that >> over time the two pieces of code will become closer together - >> hopefully for Python 3.0 we can formally merge the two. > > I was hoping that for Python 3.0, we could get around to unkludge the > sys.path/meta_path/path_hooks/path_importer_cache big ball of hacks, > possibly by replacing sys.path with something a bit more intelligent than > a plain list. +1000 I'd like to be able to simply import a file if I have the filename. And I'd like to be able to load sourcecode from an Oracle database and have useful "filename" and line number information if I get a traceback. Servus, Walter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a1 Performance
Terry Reedy wrote: > I took a look. The only thing that puzzles me is 'warp factor', which > appears exactly once. It's been put there via time machine in connection with the dilithium crystal support in that will be added in Python 7.0. You don't need to worry about it yet. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising objections
Fredrik Lundh wrote: > (distutils and setuptools are over 15000 lines of code, according to sloc- > count. Ye cats! That's a *seriously* big ball of mud. I just checked, and the whole of Pyrex is only 17000 lines. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 355 (object-oriented paths)
I didn't have a chance to comment earlier on the Path class PEP, but I'm dealing with an analogous situation at work and I'd like to weigh in on it. The issue is - should paths be specialized objects or regular strings? PEP 355 does an excellent job, I think, of presenting the case for paths being objects. And I certainly think that it would be a good idea to clean up some of the path-related APIs that are in the stdlib now. However, all that being said, I'd like to make some counter-arguments. There are a lot of programming languages out there today that have custom path classes, while many others use strings. A particularly useful comparison is Java vs. C#, two languages which have many aspects in common, but take diametrically opposite approaches to the handling of paths. Java uses a Path class, while C# uses strings as paths, and supplies a set of function-based APIs for manipulating them. Having used both languages extensively, I think that I prefer strings. One of the main reasons for this is that the majority of path manipulations are single operations - such as, take a base path and a relative path and combine them. Although you do occasionally see cases where a complex series of operations is performed on a path, such cases tend to be (a) rare, and (b) not handled well by the standard API, in the sense that what is being done to the path is not something that was anticipated by the person who wrote the path API in the first place. Given that the ultimate producers and consumers of paths (that is, the filesystem APIs, the input fields of dialog boxes, the argv array) know nothing about Path objects, the question is, is it worth converting to a special object and back again just to do a simple concatenate? I think that I would prefer to have a nice orthogonal set of path manipulation functions. Another reason why I am a bit dubious about a class-based approach is that it tends to take anything that is related to a filepath and lump them into a single module. I think that there are some fairly good reasons why different path- related functions should be in different modules. For example, one thing that irks me (and others) about the Path class in Java is that it makes no distinction between methods that are merely textual conversions, and methods which actually go out and touch the disk. I would rather that functions that invoke filesystem activity to be partitioned away from functions that merely involve string manipulation. Creating a tempfile, for example, or determining whether a file is writeable should not be in the same bucket as determining the file extension, or whether a path is relative or absolute. What I would like to see, instead, is for the various path-related functions to be organized into a clear set of categories. For example, if "os.path" is the module for pure operations on paths, without reference to the filesystem, then the current path separator character should be a member of that module, not the "os" module. -- Talin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising objections
Phillip J. Eby wrote: > If they have Pyrex installed, setuptools uses > Pyrex to rebuild the .c from the .pyx. I hope it would only do this if the .pyx was newer than the .c. It's probably not a good idea to assume that just because Pyrex is around, the user wants to use it in all cases. He might be installing a package distributed by someone with a different version of Pyrex that wasn't quite compatible. If he's not modifying the .pyx files, it would be safer to just use the provided .c files. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Software Foundation seeks mentors and students for Google Summer of Code
> Neal Norwitz <[EMAIL PROTECTED]> writes: > Please add your project ideas to the existing set at > http://wiki.python.org/moin/SummerOfCode I'd like to see ctypes supported on GCC ARM platforms. ARM is the only major Debian architecture that's not supported by ctypes. The underlying issue is lack of closure API support for ARM in libffi. I see a patch available at http://handhelds.org/~pb/arm-libffi.dpatch, that should be hopefully a good starting point. ctypes CVS has a libffi_arm_wince directory, which also seems to support closure API. Ganesan -- Ganesan Rajagopal (rganesan at debian.org) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising objections
Greg Ewing wrote: > Fredrik Lundh wrote: > > > (distutils and setuptools are over 15000 lines of code, according to sloc- > > count. > > Ye cats! That's a *seriously* big ball of mud. I just checked, > and the whole of Pyrex is only 17000 lines. correction: it's actually only 14000 lines, but it's still the largest hand- written component we have in the standard library (when combined). ~90 modules, ~120 classes. (the mac library is larger, and so is encodings, but large parts of those are autogenerated from character databases and header files. and idle is larger than distutils, but smaller than distutils+setuptools) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising objections
Anthony Baxter wrote: >>http://www.joelonsoftware.com/articles/fog69.html From what I remember, he didn't actually say that you should never rewrite anything, but that if you do, you need to be prepared for a very long period of time when nothing new is working, and that *if you are a commercial company* this is a bad idea. But Python is not dependent on getting new features out the door before its competitors in order to survive, so this doesn't really apply. It doesn't matter if people have to make do with the old distutils for a while until something better is available. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Software Foundation seeks mentors and students for Google Summer of Code
Ganesan Rajagopal wrote: >> Neal Norwitz <[EMAIL PROTECTED]> writes: > >> Please add your project ideas to the existing set at > >> http://wiki.python.org/moin/SummerOfCode > > I'd like to see ctypes supported on GCC ARM platforms. ARM is the only major > Debian architecture that's not supported by ctypes. The underlying issue is > lack of closure API support for ARM in libffi. I see a patch available at > http://handhelds.org/~pb/arm-libffi.dpatch, that should be hopefully a good > starting point. ctypes CVS has a libffi_arm_wince directory, which also > seems to support closure API. I guess you should add this idea to one of the wiki pages (or did you already, and I missed it?) Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising objections
On 4/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Anthony Baxter wrote: > > >>http://www.joelonsoftware.com/articles/fog69.html > > From what I remember, he didn't actually say that you > should never rewrite anything, but that if you do, you > need to be prepared for a very long period of time > when nothing new is working, and that *if you are a > commercial company* this is a bad idea. > > But Python is not dependent on getting new features > out the door before its competitors in order to > survive, so this doesn't really apply. It doesn't > matter if people have to make do with the old > distutils for a while until something better is > available. I think it's more a matter of scale. Rewriting small pieces of code is fine. Joel's argument applies to attempts at rewriting *entire systems* that cause massive loss of information on why things were the way they were. I don't think distutils, huge "ball of mud" as it is, hass quite crossed the size threshold that Joel was thinking of; but it *is* an extremely valuable repository of outlandish information about the bizarre details of many different platform, and as such I'd be hesitant undertaking a wholesale rewrite. I'd rather recommend the approach that Joel suggests for truly large systems: refactoring smaller components while keeping the overall structure intact. I find 100% backwards compatibility perhaps less interesting (not uninteresting, just less) than preserving the body of knowledge that is uniquely encapsulated in distutils. Unfortunately, this is mixed in with some stuff that isn't part of distutils' "core competency", like text utilities, process spawning, and option parsing. These should (eventually, when the 2.1 compatibility requirement is lifted) be refactored to use (or be merged into) the available stdlib facilities for such functionaliy. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
On Thursday 20 April 2006 17:42, Martin v. Löwis wrote: > 4. .egg files. -1 As far as I understand it, an egg file is just a zipimport format zip file with some additional metadata. You can also install the egg files in an unpacked way, if you prefer that. I don't understand the objection here - it's no better or worse than countless packages in site-packages, and if it gives us multiple versions of the same code, all the better. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
On Thursday 20 April 2006 18:18, Fredrik Lundh wrote: > I was hoping that for Python 3.0, we could get around to unkludge > the sys.path/meta_path/path_hooks/path_importer_cache big ball of > hacks, possibly by replacing sys.path with something a bit more > intelligent than a plain list. Oh please, yes. Replacing the current import code is one of the things I really really want to see in 3.0. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
On 4/20/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > 3. "package resources". I dislike the term resources (it is not about >natural gas, water, main memory, or processor cycles, right?); >instead, this seems to provide access to "embedded" data files. >Apparently, there is a need for it, so be it. -0 The "resources" name is actually quite a common meme; e.g. the Google internal API for this is in a module named "resources.py" (Google has its own set of functionality not unlike eggs). I'm also surprised you're -0 on the functionality. Lots of code has associated data files that must be distributed together with it, and IMO this is an absolutely essential feature for any packaging and distribution tool. This is another area where API standardization is important; as soon as modules are loaded out of a zip file, the traditional approach of looking relative to os.path.dirname(__file__) no longer works. > - I disliked the fact that nobody explicitly approved inclusion > of setuptools. Now that Anthony Baxter did, I'm fine. That's my fault. I told Phillip in no unclear terms that I wanted it. That was enough of an approval for me (and for Neal and Anthony, who were aware AFAIK). But I forgot to clarify this to python-dev. (Like with the proposal to turn print into a function, I assumed it was obvious that it was a good idea. :-) > - I still fear that the code of setuptools will turn out to be > a maintenance nightmare. AFAICT Phillip has explicitly promised he will maintain it (or if he doesn't, I expect that he would gladly do so if you asked). This has always been sufficient as a "guarantee" that a new module isn't orphaned. Beyond that, this objection is FUD; the circumstances of the original distutils aren't likely to be replicated here. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising objections
Guido van Rossum wrote: > I'd rather recommend the approach that Joel suggests for truly large > systems: refactoring smaller components while keeping the overall > structure intact. That's fine as long as the overall structure isn't the very thing that's wrong and needs to be fixed. Incremental refactoring is a hill-climbing approach, and there's a well-known problem with hill-climbing algorithms -- they have a tendency to get stuck on the top of a small hill and fail to find the big hill. I appreciate the loss-of-knowledge problem, I really do. But maybe there is a way of dealing with it in those cases where a change of structure really is needed. Instead of throwing away the old code, go over it line by line, sucking out the knowledge, digesting it, and incorporating it into the relevant places in the new structure. When you've finished, and all that's left of the old code is a dry, empty husk, then you can throw it away. Perhaps this process could be called "pupation" -- breaking down the old structure and building something new out of the parts, without wasting any of the original material. I'm not claiming that this necessarily has to be done with distutils, but if it did need to be done, I think it could be done, with sufficient effort. I do think that the fact nobody but the now-absent author seems to understand the internals of distutils is a very serious problem, and something needs to be done to make it easier to understand and maintain. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
On 4/20/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > On Thursday 20 April 2006 18:18, Fredrik Lundh wrote: > > I was hoping that for Python 3.0, we could get around to unkludge > > the sys.path/meta_path/path_hooks/path_importer_cache big ball of > > hacks, possibly by replacing sys.path with something a bit more > > intelligent than a plain list. > > Oh please, yes. Replacing the current import code is one of the things > I really really want to see in 3.0. Please no more "metoos" here; I've already forwarded this to the py3k list with an enthusiastic recommendation. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Software Foundation seeks mentors and students for Google Summer of Code
> Thomas Heller <[EMAIL PROTECTED]> writes: > Ganesan Rajagopal wrote: >>> Neal Norwitz <[EMAIL PROTECTED]> writes: >> >>> Please add your project ideas to the existing set at >> >>> http://wiki.python.org/moin/SummerOfCode >> >> I'd like to see ctypes supported on GCC ARM platforms. ARM is the only major >> Debian architecture that's not supported by ctypes. The underlying issue is >> lack of closure API support for ARM in libffi. I see a patch available at >> http://handhelds.org/~pb/arm-libffi.dpatch, that should be hopefully a good >> starting point. ctypes CVS has a libffi_arm_wince directory, which also >> seems to support closure API. > I guess you should add this idea to one of the wiki pages (or did you already, > and I missed it?) I started editing the page, then I thought I'd first post here to get your feedback :-). Ganesan -- Ganesan Rajagopal (rganesan at debian.org) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Software Foundation seeks mentors and students for Google Summer of Code
On 4/20/06, Ganesan Rajagopal <[EMAIL PROTECTED]> wrote: > I started editing the page, then I thought I'd first post here to get your > feedback :-). That approach doesn't scale; please use the wiki for feedback, not the mailing list (because people reading the wiki won't easily have access to the relevant feedback if it's done on the list). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
Guido van Rossum wrote: > The "resources" name is actually quite a common meme; I believe it goes back to the original Macintosh, which was the first and only computer in the world to have files with something called a "resource fork". The resource fork contained pieces of data called "resources". Then Microsoft stole the name, and before you knew, everyone was using it. It's all been downhill from there. :-) -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Software Foundation seeks mentors and students for Google Summer of Code
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes: > On 4/20/06, Ganesan Rajagopal <[EMAIL PROTECTED]> wrote: >> I started editing the page, then I thought I'd first post here to get your >> feedback :-). > That approach doesn't scale; please use the wiki for feedback, not the > mailing list (because people reading the wiki won't easily have access > to the relevant feedback if it's done on the list). Makes sense. Done. Ganesan -- Ganesan Rajagopal (rganesan at debian.org) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)
Phillip J. Eby wrote: > At 11:41 PM 4/19/2006 +1000, Nick Coghlan wrote: >> Given that naming though, I think contextlib.contextmanager should be >> renamed >> to contextlib.context. > > The name is actually correct under this terminology arrangement. > @contextmanager *returns* a context manager. That's like saying we should describe the result of calling a generator function as a generator-iterable because it has an __iter__ method. The longer name made sense when "context manager" was the term for the object with __enter__ and __exit__ methods (the way I originally wrote it when updating the PEP after the addition of the __context__ method). While I agree that flipping the terminology the other way around makes sense, it *also* flips the effect of calling a decorated generator function so that what it returns is now appropriately termed a generator-context (since it provides __enter__ and __exit__ methods directly). These contexts are context managers only in the same sense that iterators are also iterables. We shouldn't break the parallels between iterable-iterator and context manager-context without a good reason - and so far I haven't heard one. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
"Guido van Rossum wrote: > > - I still fear that the code of setuptools will turn out to be > > a maintenance nightmare. > > AFAICT Phillip has explicitly promised he will maintain it (or if he > doesn't, I expect that he would gladly do so if you asked). This has > always been sufficient as a "guarantee" that a new module isn't > orphaned. I'm not that worried about maintenance of the tool itself, but supporting "it's magic! (as long as you use the correct combination of one-letter options)" stuff is no fun at all. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 359: The "make" Statement
Steven Bethard wrote: > On 4/17/06, Russell E. Owen <[EMAIL PROTECTED]> wrote: >> At some point folks were discussing use cases of "make" where it was >> important to preserve the order in which items were added to the >> namespace. >> >> I'd like to suggest adding an implementation of an ordered dictionary to >> standard python (e.g. as a library or built in type). It's inherently >> useful, and in this case it could be used by "make". > > Not to argue against adding an ordered dictionary somewhere to Python, > but for the moment I've been convinced that it's not worth the > complication to allow the dict in which the make-statement's block is > executed to be customized. The original use case had been > XML-building, and there are much nicer solutions using the > with-statement than there would be with the make-statement. If you > think you have a better (non-XML) use case though, I'm willing to > reconsider it. I use that to define C/C++ structures to be generated in Python. I have to make some hacks to make that work with metaclasses, and I can't validate a copy-paste error that would produce two members of the same name (only the last one is kept). Please reconsider it. Regards, Nicolas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising objections
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? > > Sometimes you _have_ to rewrite. I point to > > urllib->urllib2, asyncore->twisted, rfc822/mimelib/&c->email. > > If I had the time, I would question each of these. Yes, it is > easier for the author of the new package to build "in the > green", but it is (nearly) never necessary, and almost always > bad for the project. I don't mind rewriting much, but hate leaving the original code in place; this is confusing to new users, even if it's convenient for existing users. How many HTML parsers are in the core now? (My gut feeling is that that Python's adoption curve has flattened, so it's probably now more important to keep existing users happy, so the time for jettisoning modules may be past.) --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Distutils for Python 2.1 (was "Raising objections")
On Thu, Apr 20, 2006 at 11:33:30AM +0100, Guido van Rossum wrote: > Unfortunately, this is mixed in with some stuff that isn't part of > distutils' "core competency", like text utilities, process spawning, > and option parsing. These should (eventually, when the 2.1 > compatibility requirement is lifted) be refactored to use (or be > merged into) the available stdlib facilities for such functionaliy. The 2.1 requirement was originally imposed because Greg Ward would make standalone Distutil releases. Greg is too busy working at his job, going camping on weekends, and being best man [1] to make new releases these days. I don't see anyone else wanting to make new releases, so Distutils can be like the rest of the stdlib: it'll only be guaranteed to work with the Python version it's shipped with, and can therefore use new modules. I can remove the comment from the PEP if no one objects. --amk [1] http://www.flickr.com/photos/airynothing/53483215/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)
On 4/20/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Phillip J. Eby wrote: > > At 11:41 PM 4/19/2006 +1000, Nick Coghlan wrote: > >> Given that naming though, I think contextlib.contextmanager should be > >> renamed to contextlib.context. > > > > The name is actually correct under this terminology arrangement. > > @contextmanager *returns* a context manager. > > That's like saying we should describe the result of calling a generator > function as a generator-iterable because it has an __iter__ method. > > The longer name made sense when "context manager" was the term for the object > with __enter__ and __exit__ methods (the way I originally wrote it when > updating the PEP after the addition of the __context__ method). > > While I agree that flipping the terminology the other way around makes sense, > it *also* flips the effect of calling a decorated generator function so that > what it returns is now appropriately termed a generator-context (since it > provides __enter__ and __exit__ methods directly). > > These contexts are context managers only in the same sense that iterators are > also iterables. We shouldn't break the parallels between iterable-iterator and > context manager-context without a good reason - and so far I haven't heard > one. 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. (Yet another analogy: if generators had to be decorated explicitly, we'd name it @generator, even though what it returns when called is properly an iterator.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3rd party extensions hot-fixing the stdlib (setuptools in the stdlib)
Phillip J. Eby wrote: >> Why should a 3rd party extension be hot-fixing the standard >> Python distribution ? > Because setuptools installs things in zip files, and older versions of > pydoc don't work for packages zip files. That doesn't answer my question. >>> That is the answer to the question you asked: "why hot-fix?" Because >>> setuptools uses zip files, and older pydocs crash when trying to display >>> the documentation for a package (not module; modules were fine) that is in >>> a zip file. >> I fail to see the relationship between setuptools and pydoc. > > People blame setuptools when pydoc doesn't work on packages in zip > files. Rather than refer to some theoretical argument why it's not my > fault and I shouldn't be the one to fix it, I prefer to fix the problem. And people come to python-dev to complain about why a Python patch level release doesn't seem to fix some other problem in that same code that is documented to be fixed in the release. Don't you realize the general problem with this kind of approach ? BTW: if setuptools would stop defaulting to using .egg files as means of installation and instead default to using their unzipped form, the problem would go away and setuptools would again be in line with the Python standard of installing modules and packages. (For the interested: see my reply to Anthony for details or the fruitless discussions on distutils-sig on this matter.) >> The setuptools distribution is not the authoritative source for >> these kinds of fixes and that should be made clear by separating >> those parts out into a different package and making the >> installation an explicit user option. > > ...which nobody will use, following which they will still blame setuptools > for pydoc's failure. > > But I do agree that it might be a good idea to: > > 1) tell people about the issue > 2) tell people that the fix is being installed > 3) make it easy to remove the fix > > However, maybe I should just create 'pydoc-hotfix' and 'doctest-hotfix' > packages on PyPI and then tell people to "easy_install pydoc-hotfix > doctest-hotfix". Yes, please ! Please use a different name for these hot-fixes, though, so that it's clear that they only apply to specific Python versions and are in fact, back-ports of Python 2.5 versions of those modules. > Or perhaps just create a "pep302-hotfixes" package that > includes all of the PEP 302 support changes for linecache, traceback, and > so on, although I'm not sure how many of those can be installed in such a > way that the fixes would be active prior to the stdlib versions being imported. > > I suppose I could handle the "nobody will use it" problem by having > easy_install nag about the hotfixes not being installed when running under > 2.3 or 2.4. Fair enough. >> You should also note that users won't benefit from bug fixed >> versions of e.g. such modules in patch level releases. > > The pydoc fixes to support zip files are too extensive to justify > backporting, as they rely on features provided elsewhere. So if bug fixes > occur on the 2.5 trunk, I would have to update the hotfix versions directly. Right. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 20 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils for Python 2.1 (was "Raising objections")
A.M. Kuchling wrote: > The 2.1 requirement was originally imposed because Greg Ward would > make standalone Distutil releases. Greg is too busy working at his > job, going camping on weekends, and being best man [1] to make new > releases these days. from python-announce: From: Greg Ward Subject: ANNOUNCE: Optik 1.5.1 Date: 2006-04-20 01:46:20 GMT Optik 1.5.1 is now available, just 16 months after I first planned to release it (sigh). ... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5. (summary)
Anthony Baxter wrote: > In an attempt to help this thread reach some sort of resolution, > here's a collection of arguments against and in favour of setuptools > in 2.5. My conclusions are at the end. Thanks for the summary. I'd like to add some important aspects (for me at least) that are missing: - setuptools should not change the standard distutils "install" command to install everything as eggs Eggs are just one distribution format out of many. They do server their purpose, just like RPMs, DEBs or Windows installers do. However, when running "python setup.py install" you are in fact installing from source, so there's no need to wrap things up again. The distutils default of actually installing things in the standard Python is good, has worked for years and should continue to do so. The extra information needed by the dependency checking can easily be added to the package directory of the installed package or stored elsewhere in a repository of installed packages or as separate egg-info directory if we want to stick with setuptools' way of using the path name for getting meta-information on a package. Placing the egg-files into the system as ZIP files should be an option, e.g. as separate "install_egg" command, not the default. - setuptools includes many good additions to distutils We should remember that setuptools will get part of the stdlib, so instead of monkey-patching distutils, a lot of setuptools features can be ported to distutils directly. For things that don't fit distutils, proper hooks should be added, so that extending distutils in the setuptools way can be done by the standard distutils extension mechanisms. I think that if Phillip were more open to reconsidering design decisions in setuptools like the decision to replace the install command instead of just adding a new install_egg command (together with a bdist_egg), quite a lot of code could be directly imported into core distutils. Even for things like his alternative sdist implementation could go in, albeit using a different command name. - arguments like "just works" simply don't count Why not ? Because "just works" is not well-defined. If an implementation makes too many magical decisions for the user, you end up with a tunnel - with only one way in and one way out. In reality there are too many things you'd need magical decisions for. A generic distribution mechanism will never be capable of making all the right decisions for a user. Adding endless lists of options doesn't make things easier either. Let's face it: there isn't the one right way to do software distribution. What's good about it: there doesn't need to be. The package authors will know which particular tweaks are needed to make installing their package a breeze and easy for the user. So the right way to get close the "just works" idea, is to leave a door open for module authors and packages to add such functionality. Freedom of choice is often enough a lot better than any variant of "just works". Explicit is better than implicit. Good defaults help. - setuptools is not ready for prime-time This is not quite right. setuptools works and has been used by quite a few people in the past. However, just dumping setuptools into the stdlib is considered a less than ideal approach. Instead, setuptools should get *integrated* into the stdlib. This process will take longer than the current 2.5 release cycle. We should at least mark setuptools as it is now in the stdlib as experimental and leave open the possibility of making changes to it. > The arguments against: > > - Someone should instead just fix distutils. > >Right. And the amount of yelling if distutils changed in a non-b/w > compat way wouldn't be high. There's also the basic problem that the > distutils code is _horrible_. > > - It monkeypatches pydoc and distutils! > >It only monkeypatches pydoc when the separate setuptools installer > is used on older Pythons. How is this relevant for this discussion of > Python 2.5? The monkeypatching for distutils should be reduced - see > AMK's message for a breakdown of this. > > - Documentation > >beaker% pydoc xmlcore.etree >no Python documentation found for 'xmlcore.etree' > >beaker% pydoc ctypes >no Python documentation found for 'ctypes' > >The documentation (of which there is plenty) can and will be folded > into the standard python docs. Most of the new modules in 2.5 went in > before their docs. > > - Where's the PEP? > >I don't see the need. The stuff that could go into a PEP about > formats and the like should go into the existing Distutils > documentation. It's a far more useful place, and many more people are > likely to find it there than in a PEP. The PEP is needed to document the current discussion, not the setuptools technical documentation (this should of course go
Re: [Python-Dev] Raising objections
On Thu, Apr 20, 2006, A.M. Kuchling wrote: > > I don't mind rewriting much, but hate leaving the original code in > place; this is confusing to new users, even if it's convenient for > existing users. How many HTML parsers are in the core now? (My gut > feeling is that that Python's adoption curve has flattened, so it's > probably now more important to keep existing users happy, so the time > for jettisoning modules may be past.) There's a lot of truth for that with Python 2.x, but that's what 3.0 is for. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Argue for your limitations, and sure enough they're yours." --Richard Bach ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising objections
On Thu, 2006-04-20 at 07:53 +0200, "Martin v. Löwis" wrote: > > Sometimes you _have_ to rewrite. I point to > > urllib->urllib2, asyncore->twisted, rfc822/mimelib/&c->email. > > If I had the time, I would question each of these. Yes, it is > easier for the author of the new package to build "in the > green", but it is (nearly) never necessary, and almost always > bad for the project. Actually, it's not always easier to rewrite from scratch. In fact, I think it's rarely easier to do so than to just patch up bugs here and there in something that already exists, or wedge in hacks to minimally extend it to keep up with new standards or uses. But sometimes the fundamental model of how something works just will no longer cut it, and something better must be designed, argued about, written, tested, documented, beta released, feedback gathered, bugs accepted, patches accepted, re-released, maintained, backward compatibility supported forever, etc. etc. Oh wait, yes definitely easier to rewrite . way-off-topic-now-ly y'rs, -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
> The arguments against: One more: - Installing a package means dropping files in the system without any kind of record keeping. It should learn from the techniques applied in other well-known package managers (RPM, DPKG, whatever) to keep track of what's happening in the system. -- Gustavo Niemeyer http://niemeyer.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] proposal: evaluated string
many times, templating a string is a tidious task. using the % operator, either with tuples or dicts,is difficult to maintain, when the number of templated arguments is large. and string.Template,although more easy to read, is less intutive and cumbersome:
import stringt = string.Template("hello $name")print t.substitute({"name" : "john"})as you can see, it is is redundant, as you must repeat the dict keys in two places, and imagine
maintaining such a template with 20 parameters! if you change the one argument's name in the template, you must go and fix all locations that use that template. not nice at all.i'm suggesting something like boo's string interpolation:
http://boo.codehaus.org/String+Interpolationbut i chose to call it "evaluated string".like raw strings (r""), which are baiscally a syntactic sugar, evaluated strings will be marked by 'e',
for instance, e"", which may be combined with the 'r' or 'u', that exist today.the evaluated string will be evaluated based on the current scope (locals and globals), just likenormal expressions. the difference is, the results of the expressions will be str()ed into the
evaluated string directly. these expressions will be embedded into the string surrounded byspecial delimiters, and an unclosed delimited or a syntax error will be reported at just like "\x??"raises "ValueError: invalid \x escape".
i'm not sure which delimiters to use, but i think only { } is sufficient (no need for ${ } like in boo)some examples:===name = "john"print e"hello {name}"
a = 3b = 7print e"the function is y = {a}x + {b}"for x in range(10): print e"y({x}) = {a*x+b}"import time, sysprint e"the time is {time.asctime()} and you are running on {
sys.platform}"===in order to implement it, i suggest a new type, estr. doing a = e"hello"will be equivalent to a = estr("hello", locals(), globals()), just like
u"hello"is equivalent tounicode("hello") (if we ignore \u escaping for a moment)and just like unicode literals introduce the \u escape, estr literals would introduce \{ and \}
to escape delimiters.the estr object will be evaluated with the given locals() and globals() only at __repr__ or __str__,which means you can work with it like a normal string:a = e"hello {name} "
b = e"how nice to meet you at this lovely day of {time.localtime().tm_year}"c = a + bc is just the concatenation of the two strings, and it will will be evaluated as a whole when youstr()/repr() it. of course the internal representation of the object shouldnt not as a string,
rather a sequence of static (non evaluated) and dynamic (need evaluation) parts, i.e.:["hello", "name", "how nice to meet you at this lovely day of", "time.localtime().tm_year"],
so evaluating the string will be fast (just calling eval() on the relevant parts)also, estr objects will not support getitem/slicing/startswith, as it's not clear what the indexes are...
you'd have to first evaluate it and then work with the string:str(e"hello")[2:]estr will have a counterpart type called eunicode. some rules:estr + str => estrestr + estr => estrestr + unicode => eunicode
estr + eunicode => eunicodeeunicode + eunicode => eunicodethere are no backwards compatibility issues, as e"" is an invalid syntax today, and as for clarity, i'm sure editors like emacs and the like can be configured to highlight the strings enclosed by {}
like normal expressions.i know it may cause the perl-syndrome, where all the code of the program is pushed into strings,but templating/string interpolation is really a fundamental requirement of scripting languages,
and the perl syndrome can be prevented with two precautions:* compile the code with "eval" flag instead of "exec". this would prevent abominations likee"{import time\ndef f(a):\n\tprint 'blah'}"
* do not allow the % operator to work on estr's, to avoid awful things likee"how are %s {%s}" % ("you", "name")one templating mechanism at a time, please :)perhaps there are other restrictions to impose, but i couldnt think of any at the moment.
here's a proposed implementation:class estr(object): # can't derive from basestring! def __init__(self, raw, locals, globals): self.elements = self._parse(raw) self.locals = locals
self.globals = globals def _parse(self, raw): i = 0 last_index = 0 nesting = 0 elements = [] while i < len(raw): if raw[i] == "{":
if nesting == 0: elements.append((False, raw[last_index : i])) last_index = i + 1 nesting += 1 elif raw[i] == "}":
nesting -= 1 if nesting == 0: elements.append((True, raw[last_index : i])) last_index = i + 1 if nesting < 0: raise ValueError("too many '}' (at index %d)" % (i,))
i += 1 if nesting > 0: raise ValueError("missing '}' before end") if last_index < i:
Re: [Python-Dev] Raising objections
On Thu, 2006-04-20 at 11:33 +0100, Guido van Rossum wrote: > Unfortunately, this is mixed in with some stuff that isn't part of > distutils' "core competency", like text utilities, process spawning, > and option parsing. These should (eventually, when the 2.1 > compatibility requirement is lifted) be refactored to use (or be > merged into) the available stdlib facilities for such functionaliy. With today's svn repo, I don't think there's any need to force Python 2.5's version to pay for the backward compatibility with earlier versions. This is what I do with the email package for example. In the sandbox, I have externals to Python 2.3's version for email 2.5, Python 2.4's version for email 3.0, and Python 2.5's version for email 4.0. Yes, it's more work to maintain three branches, but it's manageable. So it's not due to lack of structural support that we have to keep forward porting a package's baggage, but only the distutils/setuptools maintainers can decide whether it's too much work to maintain multiple branches. And there's a lot of joy to be derived from removing lots of backward compatibility crap. (It's always more fun to remove code than add new code :). At some point you have to move on. Python 2.1 and 2.2 are getting increasingly difficult to support, and I've found less and less call for it from my users. OTOH, Python 2.3 is still very popular, so that's now my minimum requirement. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 355 (object-oriented paths)
Talin, everything you wrote is really compelling. If path.py weren't
so ridiculously useful to me, I would be completely convinced. :)
For example, I agree 100% with this:
> Another reason why I am a bit dubious about a class-based approach
> is that it tends to take anything that is related to a filepath and lump
> them into a single module.
...and this:
> one thing that irks me (and others) about the Path class in Java is
> that it makes no distinction between methods that are merely textual
> conversions, and methods which actually go out and touch the disk.
...until I remember that in practice, d.parent and d.files('*.txt') on
the same object; or f.ext and f.isfile(); are things I do all the time
without thinking. I think I can see why.
Separate modules only make sense for separate use cases. In
real-world code where you're "doing stuff with files and directories",
you're going to randomly need os.remove(), shutil.copyfile(),
os.path.isdir(), and/or glob.glob(). I have one big mental junk
drawer with all this stuff in it. The way the stdlib partitions them
does not fit my brain. I have trouble believing some other
theoretical partition would be much better, though I'd love to see
someone try.
Lastly-- Is nontrivial path manipulation really rare? Practically
every program I write "does stuff with files and directories".
Scripts often do little else; in larger programs, main() often does 5
or 50 lines of this kind of stuff, while the rest of the program is
mostly filesystem-unaware.
-j
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] need info for externally maintained modules PEP
Brett Cannon wrote: > > Not sure whether Fredrik Lundh has responded, but I believe he once > > said that he would prefer if ElementTree isn't directly modified, but > > that instead patches are filed on the SF tracker and assigned to him. > > Nope, Fredrik never responded. I am cc:ing him directly to see if he > has a preference along with Gerhard to see if he has one as well for > pysqlite. martin's memory is flawless, as usual. applying emergency patches (stuff that blocks the build, and security fixes) is of course okay, but I would prefer if everything else is handled via the ET master repository. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] SVN question
I'm about to import the 0.9.9.6 tag of ctypes into Python svn. Should this be done in exact the same way as before, so first commit it into external/ctypes-0.9.9.6, and then 'svn copy' the two relevant directories into the trunk, and afterwards set all the svn props again, or is this done in another way? Thanks, Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVN question
Thomas Heller wrote: > I'm about to import the 0.9.9.6 tag of ctypes into Python svn. > > Should this be done in exact the same way as before, so first > commit it into external/ctypes-0.9.9.6, and then 'svn copy' > the two relevant directories into the trunk, and afterwards set > all the svn props again, or is this done in another way? what props? if you prefer, you could switch to using "vendor drop" approach for ctypes. see this page for an explanation: http://svnbook.red-bean.com/en/1.0/ch07s04.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
Anthony> Finally, I'd like to point out that I think some of the Anthony> hostility towards Phillip's work has been excessive. He's done Anthony> an amazing amount of work on this (look at the distutils-sig Anthony> archive for the last two years for more), and produced Anthony> something that's very very useful. Anthony> He deserves far more credit for this than he seems to have been Anthony> getting here. I agree. I'll go one step further and suggest that not only should setuptools be included in the stdlib but that distutils should be deprecated, at least as a user-visible package. I've not looked at the setuptools code, but I have tried at times to use the distutils code. Those were trying times. I've also seen some of the rapid acceptance of setuptools in the broader Python community. Maybe they know something we don't. Thank you Phillip... Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Google Summer of Code proposal: Pdb improvments
I've found thread on python-dev related to pdb's weaknesses: http://www.mail-archive.com/[email protected]/msg05115.html The opinions are that pdb is 'one of the more unPythonic modules' and must be 'seriously fixed'.I have similar experience with pdb's internals but I want to know others opinion. I'm currently trying to answer following questions: What should be fixed first in pdb? What we could do to make pdb better debugging utility? If you have any suggestions related to pdb's improvements please put them to the wiki page: http://wiki.python.org/moin/PdbImprovments Is this kind of proposal to the SoC would be accepted by some of the psf mentors? jkk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising objections
Anthony> I don't think it's fair to say that Phillip just checked this Anthony> in off on his own. In addition, since he did the development in the Python sandbox, his checkins all along have been there for everyone to see. It's not like he did the work in Outer Mongolia then showed up one day checked it in while everyone was sleeping. I see mention of "setuptools" in the distutils-sig archive at least as far back as May 2005 and mention of "eggs" back to at least April 2005. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in the stdlib ([Python-checkins] r45510 - python/trunk/Lib/pkgutil.py python/trunk/Lib/pydoc.py)
Martin> c) ask for consent in advance to making a potentially-breaking Martin>change. Doesn't that potentially extend the release time for an enhanced distutils across multiple Python releases? With both distutils and setuptools available simultaneously, setuptools can be designed and implemented to suit the needs of its constituency while distutils remains avilable and compatible for those people using it. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] proposal: evaluated string
"tomer filiba" <[EMAIL PROTECTED]> wrote: > the evaluated string will be evaluated based on the current scope (locals > and globals), just like > normal expressions. the difference is, the results of the expressions will > be str()ed into the > evaluated string directly. these expressions will be embedded into the > string surrounded by -1 You are basically suggesting that e"..." be a replacement for "..."%locals() . That doesn't seem to me to be sufficiently compelling (yes, I do use string interpolation). - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
[EMAIL PROTECTED] wrote: > Maybe they know something we don't. oh, please. it's not like people like myself and MAL don't know anything about package distribution... (why is it that people who *don't* distribute stuff are a lot more im- pressed by a magic tool than people who've spent the last decade distributing stuff ? has it ever occurred to you that we know some- thing that you don't ?) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] need info for externally maintained modules PEP
Fredrik> applying emergency patches (stuff that blocks the build, and Fredrik> security fixes) is of course okay, but I would prefer if Fredrik> everything else is handled via the ET master repository. Could that reference be placed in a comment near the top of xmlcore/etree/ElementTree.py or in a README file in the etree package? Thx, Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] proposal: evaluated string
just like r"" does the escaping for you.but estr types must be implemented so the evaluate with the current scope (locals and globals),not the score they were defined it, so unless you want to do nasty tricks with sys._getframe, which doesn't work on all implementations of python, you'll need it as a builtin-tomerOn 4/20/06, Josiah Carlson < [EMAIL PROTECTED]> wrote:"tomer filiba" < [EMAIL PROTECTED]> wrote:> the evaluated string will be evaluated based on the current scope (locals> and globals), just like> normal expressions. the difference is, the results of the expressions will > be str()ed into the> evaluated string directly. these expressions will be embedded into the> string surrounded by-1 You are basically suggesting that e"..." be a replacement for "..."%locals() . That doesn't seem to me to be sufficiently compelling(yes, I do use string interpolation). - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] proposal: evaluated string
tomer filiba wrote:
> many times, templating a string is a tidious task. using the %
> operator, either with tuples or dicts,
> is difficult to maintain, when the number of templated arguments is
> large. and string.Template,
> although more easy to read, is less intutive and cumbersome:
>
> import string
> t = string.Template("hello $name")
> print t.substitute({"name" : "john"})
Using the key twice is basic to templating (once of specify where to
make the substitution and once to specify its value). This is no
different from using variable names in regular code: a=1; ... ; b =
a+2 # variable-a is used twice.
Also, the example is misleading because real-apps are substitute
variables, not constants. IOW, the above code fragment is sematically
equivalent to: print "hello john".
> i'm suggesting something like boo's string interpolation:
> http://boo.codehaus.org/String+Interpolation
We already have a slew of templating utilities (see Cheetah for example).
> but i chose to call it "evaluated string".
>
> like raw strings (r""), which are baiscally a syntactic sugar,
> evaluated strings will be marked by 'e',
> for instance, e"", which may be combined with the 'r' or 'u', that
> exist today.
>
> the evaluated string will be evaluated based on the current scope
> (locals and globals), just like
> normal expressions. the difference is, the results of the expressions
> will be str()ed into the
> evaluated string directly. these expressions will be embedded into the
> string surrounded by
> special delimiters, and an unclosed delimited or a syntax error will
> be reported at just like "\x??"
> raises "ValueError: invalid \x escape".
>
> i'm not sure which delimiters to use, but i think only { } is
> sufficient (no need for ${ } like in boo)
>
> some examples:
> ===
> name = "john"
> print e"hello {name}"
The string.Template() tool already does this right out of the box:
>>> print Template('hello $name').substitute(globals())
hello john
So, essentially the proposal is to make the globals() access implicit
and to abbreviate the Template constructor with new syntax. The latter
is not desirable because 1) it is less readable, 2) string prefixing is
already out-of-control (used for raw strings and unicode), 3) it is less
flexible than the class constructor which can be subclassed and
extended as needed.
If you don't like the $name style of template markup and prefer
delimiters instead, then check-out the recipe at:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/3053
> a = 3
> b = 7
> print e"the function is y = {a}x + {b}"
> for x in range(10):
> print e"y({x}) = {a*x+b}"
>
> import time, sys
> print e"the time is {time.asctime()} and you are running on {
> sys.platform}
If you need this, then consider using a third-party templating module.
Be sure to stay aware of the security risks if the fill-in values are
user specified.
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] proposal: evaluated string
> >If you don't like the $name style of template markup and prefer >delimiters instead, then check-out the recipe at: > >http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/3053 > > The link should have been: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/305306 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] proposal: evaluated string
We already have a slew of templating utilities (see Cheetah for example).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. like boo does. and estr is stronger than simple $name substitution, like Template does.
Be sure to stay aware of the security risks if the fill-in values are user specified.that's one major benefit of having it as a builtin type -- you dont have security risks,as the _expression_ itself is embedded in your code, not something you get from the
outside:name = raw_input("what's you name?")print e"hello {name}"does not get the *_expression_* from the user, only the *values*, so unless the usercauses a buffer overflow with a huge string, he can't run code. the estr object is part
of *your* code, which you trust. If you need this, then consider using a third-party templating module.
that 50-liner estr class i presented does just that.Using the key twice is basic to templating (once of specify where to
make the substitution and once to specify its value). This is nodifferent from using variable names in regular code: a=1; ... ; b =a+2 # variable-a is used twice.but when it's defined once as an argument to a function, once in the template,
and once in the dict, that's three times, where it can be only two.def f(name): print e"hello {name}"
Also, the example is misleading because real-apps are substitutevariables, not constants. IOW, the above code fragment is sematicallyequivalent to: print "hello john".what do you mean by that?
3) it is lessflexible than the class constructor which can be subclassed and
extended as needed.do you often subclass str? it's a built-in type, part of the language, subclassing it doesntmake much sense. after all it's the language compiler that instanciates these types,
i.e.,when you do "hello", the compiler creates an instance of str() with that value, not youdirectly, and that's the case here.-tomerOn 4/20/06,
Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>If you don't like the $name style of template markup and prefer>delimiters instead, then check-out the recipe at:>>
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/3053>>The link should have been: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/305306
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] proposal: evaluated string
Tomer, please stop. We've seen your proposal. We've said "-1". Please
take it instead of wasting your time trying to argue for it.
On 4/20/06, tomer filiba <[EMAIL PROTECTED]> wrote:
>
> > We already have a slew of templating utilities (see Cheetah for example).
> >
> 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. like boo does. and estr is stronger than
> simple
> $name substitution, like Template does.
>
>
> > Be sure to stay aware of the security risks if the fill-in values are user
> specified.
> >
> that's one major benefit of having it as a builtin type -- you dont have
> security risks,
> as the expression itself is embedded in your code, not something you get
> from the
> outside:
>
> name = raw_input("what's you name?")
> print e"hello {name}"
>
> does not get the *expression* from the user, only the *values*, so unless
> the user
> causes a buffer overflow with a huge string, he can't run code. the estr
> object is part
> of *your* code, which you trust.
>
>
> > If you need this, then consider using a third-party templating module.
> >
> that 50-liner estr class i presented does just that.
>
>
> > Using the key twice is basic to templating (once of specify where to
> > make the substitution and once to specify its value). This is no
> > different from using variable names in regular code: a=1; ... ; b =
> > a+2 # variable-a is used twice.
> >
> but when it's defined once as an argument to a function, once in the
> template,
> and once in the dict, that's three times, where it can be only two.
>
> def f(name):
> print e"hello {name}"
>
>
> > Also, the example is misleading because real-apps are substitute
> > variables, not constants. IOW, the above code fragment is sematically
> > equivalent to: print "hello john".
>
>
> what do you mean by that?
>
>
> > 3) it is less
> > flexible than the class constructor which can be subclassed and
> > extended as needed.
> >
> do you often subclass str? it's a built-in type, part of the language,
> subclassing it doesnt
> make much sense. after all it's the language compiler that instanciates
> these types, i.e.,
> when you do "hello", the compiler creates an instance of str() with that
> value, not you
> directly, and that's the case here.
>
>
> -tomer
>
>
> On 4/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >If you don't like the $name style of template markup and prefer
> > >delimiters instead, then check-out the recipe at:
> > >
> > >
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/3053
> > >
> > >
> > The link should have been:
> >
> >
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/305306
> >
> >
> >
> >
>
>
> ___
> Python-Dev mailing list
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] proposal: evaluated string
We've said "-1"i don't mean to be rude, but only josiah strictly said -1. by you saying "we",
i'd assume you -1'ed it as well, but you couldn't have expected me to know that beforeyou said it. so i feel a little cornered here... is it my fault i don't support quantom superposition?-tomer
On 4/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Tomer, please stop. We've seen your proposal. We've said "-1". Pleasetake it instead of wasting your time trying to argue for it.On 4/20/06, tomer filiba <[EMAIL PROTECTED]
> wrote:>> > We already have a slew of templating utilities (see Cheetah for example).> >> 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. like boo does. and estr is stronger than> simple> $name substitution, like Template does.>>> > Be sure to stay aware of the security risks if the fill-in values are user
> specified.> >> that's one major benefit of having it as a builtin type -- you dont have> security risks,> as the _expression_ itself is embedded in your code, not something you get
> from the> outside:>> name = raw_input("what's you name?")> print e"hello {name}">> does not get the *_expression_* from the user, only the *values*, so unless
> the user> causes a buffer overflow with a huge string, he can't run code. the estr> object is part> of *your* code, which you trust.>>> > If you need this, then consider using a third-party templating module.
> >> that 50-liner estr class i presented does just that.>>> > Using the key twice is basic to templating (once of specify where to> > make the substitution and once to specify its value). This is no
> > different from using variable names in regular code: a=1; ... ; b => > a+2 # variable-a is used twice.> >> but when it's defined once as an argument to a function, once in the
> template,> and once in the dict, that's three times, where it can be only two.>> def f(name):> print e"hello {name}">>> > Also, the example is misleading because real-apps are substitute
> > variables, not constants. IOW, the above code fragment is sematically> > equivalent to: print "hello john".>>> what do you mean by that?>>> > 3) it is less
> > flexible than the class constructor which can be subclassed and> > extended as needed.> >> do you often subclass str? it's a built-in type, part of the language,> subclassing it doesnt
> make much sense. after all it's the language compiler that instanciates> these types, i.e.,> when you do "hello", the compiler creates an instance of str() with that> value, not you
> directly, and that's the case here.>>> -tomer>>> On 4/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:> >
> > >> > >If you don't like the $name style of template markup and prefer> > >delimiters instead, then check-out the recipe at:> > >> > >>
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/3053> > >> > >> > The link should have been:> >> >>
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/305306> >> >> >> ___> Python-Dev mailing list
> [email protected]> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
Fredrik Lundh wrote: > [EMAIL PROTECTED] wrote: >>Maybe they know something we don't. > > oh, please. it's not like people like myself and MAL don't know anything > about package distribution... > > (why is it that people who *don't* distribute stuff are a lot more im- > pressed by a magic tool than people who've spent the last decade > distributing stuff ? has it ever occurred to you that we know some- > thing that you don't ?) There's many people packaging and distributing code with setuptools, but very few of them are on this list. Setuptools has gotten quite a lot of use and a lot of pushback from people, but only from the people who have been using it. People who have complained about Setuptools without using it have had little influence, because most of their suggestions are only resolvable by having Setuptools simply cease to exist, which is not very constructive. But even then, I've seen Phillip make many changes to Setuptools based on feedback from people who just wanted Setuptools to get out of their way; but again, you have to at least be using it to give this kind of feedback. And somewhat tangential, but related to much of this discussion: if Phillip had been doing developments for distutils all this time instead of making a package that was separately installable under a different name, Setuptools would never have gotten the use and feedback that is has so far received. We could turn this into a discussion about how to handle updates to the standard library, but given the constraints I think Setuptools was developed in the best way possible. If development had happened here on python-dev and released to the large community only with the next Python release, Setuptools would be far inferior to its current state. And now for a little pushback the other way -- as of this January TurboGears has served up 100,000 egg files (I'm not sure what the window for all those downloads is, but it hasn't been very long). Has it occurred to you that they know something you don't about distribution? ElementTree would be among those egg files, so you should also consider how many people *haven't* asked you about problems related to the installation process. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
Anthony Baxter wrote: >> 4. .egg files. -1 > > As far as I understand it, an egg file is just a zipimport format zip > file with some additional metadata. You can also install the egg > files in an unpacked way, if you prefer that. I don't understand the > objection here - it's no better or worse than countless packages in > site-packages, and if it gives us multiple versions of the same code, > all the better. It is worse: each .egg file makes an additional sys.path entry (if I understand correctly); every import statement will traverse every every package. I'm not sure precisely how all this works, but I wouldn't be surprised if the zip directory is read over and over again. Compare that to countless packages in site-packages: "import foo" will *just* look for foo.py, foo.so, and the directory foo. I understand there is a second API to importing, some kind of "require()" call. I consider that even worse: it obsoletes the language's mechanism for modules, and defines its own modularization. However, this isn't really my objection to .egg files. I dislike them because they compete with platform packages: .rpm, .msi, .deb. Package authors will refuse to produce them, putting the burden of package maintenance (what packages are installed, what are their dependencies, when should I remove a package) onto the the end user/system administrator. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
Guido van Rossum wrote: > This is another area where API standardization is > important; as soon as modules are loaded out of a zip file, the > traditional approach of looking relative to os.path.dirname(__file__) > no longer works. Certainly. However, I get two conclusions out of this: 1. don't load packages out of .zip files. It's not that bad if software on the user's disk occupies multiple files, as long as there is a convenient way to get rid of them at once. Many problems go away if you just say no to zipimport. 2. standardize on file names, not API. If I want to deploy read-only data files, I put them into /usr/share. If I need read-write files, I put them into /var. I did not have such a problem yet on other systems, but I would also try to follow the conventions of these systems. With these combined, I can use any API I like to operate on the files. distutils already has support for that. 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. I consider this approach flawed: once I leave the realm of KDE programs, this all stops working. It is the operating system's job to provide unified access to storage, not the programming language's or the job of a library. >> - I still fear that the code of setuptools will turn out to be >> a maintenance nightmare. > > AFAICT Phillip has explicitly promised he will maintain it (or if he > doesn't, I expect that he would gladly do so if you asked). This has > always been sufficient as a "guarantee" that a new module isn't > orphaned. He has, and it is. Still, for whatever reason, I feel particularly uneasy here (and yes, that is my fear, my uncertainty, and my doubt). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in the stdlib ([Python-checkins] r45510 - python/trunk/Lib/pkgutil.py python/trunk/Lib/pydoc.py)
[EMAIL PROTECTED] wrote: > Martin> c) ask for consent in advance to making a potentially-breaking > Martin>change. > > Doesn't that potentially extend the release time for an enhanced distutils > across multiple Python releases? Yes, but your alternative doesn't "scale" over time. At some point, modifying setuptools will not be acceptable anymore because of the risk of breaking packages that rely on intimate details of setuptools. What are we going to do then? The "natural" expansion is this: Invent a new library, say, setuplib, which sits on top of setuptools, and then (copying) "setuplib can be designed and implemented to suit the needs of its constituency while setuptools remains available and compatible for those people using it." People will just have to replace from setuptools import setup with from setuplib import setup The new setuplib will be completely transparent: if you don't explicitly use it, nothing will change. Sarcasm aside, this isn't a good approach to software versioning, IMO. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] windows buildbot failures
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)
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
On 20-apr-2006, at 21:53, Martin v. Löwis wrote: > > However, this isn't really my objection to .egg files. I dislike them > because they compete with platform packages: .rpm, .msi, .deb. As far as I understand the issues they compete up to a point, but should also make it easier to create platform packages that contain proper the proper dependencies because those are part of machine-readable meta-data instead of being written down in readme files. Oddly enough that was also the objection from one linux distribution maintainer: somehow his opinion was that the author of a package couldn't possibly know the right depedencies for it. As for platform packages: not all platforms have useable packaging systems. MacOSX is one example of those, the system packager is an installer and doesn't include an uninstaller. Eggs make it a lot easier to manage python software in such an environment (and please don't point me to Fink or DarwinPorts on OSX, those have serious problems of their own). > Package > authors will refuse to produce them, putting the burden of package > maintenance (what packages are installed, what are their dependencies, > when should I remove a package) onto the the end user/system > administrator. Philip has added specific support for them: it is possible to install packages in the tradition way but with some additional files that tell setuptools about installed packages. Maybe 'python setup.py install' should default to installing in that mode (as someone else already suggest), with either on option or a seperate command to install as eggs. Ronald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] proposal: evaluated string
"tomer filiba" <[EMAIL PROTECTED] >i don't mean to be rude, Then don't be. Your worst was the silly suggestion in an ad hominen barb that a contributor of many years does not belong on this list. But this time-wasting quibble post, in response to a request to quit wasting everyone's time, comes close. > but only josiah strictly said -1. By including 'strictly', you seem to me to be effectively admitting that you are smart enough to have noticed that Raymond 'effectively' said -1 in his explanation of why he rejected your idea. Since Guido was responding to your argumentative response to Raymond, he was obviously including Raymond as someone who has *effectively* said -1. > is it my fault i don't support quantom superposition? Yes and no, or maybe maybe ;-) Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
Bob Ippolito wrote: > They DO NOT compete any more than source packages do. eggs are packages > plus metadata, nothing more. What eggs do and what rpm/msi/deb does are > orthogonal. It's entirely reasonable that in the future rpm/msi/deb > will simply be a delivery mechanism for eggs. That might be your view, but it apparently isn't the view of the inventor(s). From http://peak.telecommunity.com/DevCenter/setuptools Create Python Eggs - a single-file importable distribution format http://peak.telecommunity.com/DevCenter/PythonEggs '"Eggs are to Pythons as Jars are to Java..."' 'There are several binary formats that embody eggs, but the most common is '.egg' zipfile format, because it's a convenient one for distributing projects.' '.egg files are a "zero installation" format for a Python package;' So the .egg inventors do view .egg files (i.e. the .egg zipfile format) as a distribution format, just like rpm/msi/deb *are* distribution formats (none of them "zero installation", though, you always have to perform some deployment activity). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5. (summary)
M.-A. Lemburg wrote: > Anthony Baxter wrote: > >>In an attempt to help this thread reach some sort of resolution, >>here's a collection of arguments against and in favour of setuptools >>in 2.5. My conclusions are at the end. > > > Thanks for the summary. I'd like to add some important aspects > (for me at least) that are missing: > > - setuptools should not change the standard distutils "install" > command to install everything as eggs > > Eggs are just one distribution format out of many. They do > server their purpose, just like RPMs, DEBs or Windows installers do. I think Eggs can be a bit confusing. They really serve two purposes, but using the same format. They are a distribution mechanism, which is probably one of the less important aspects, and there's the installation format. So you don't have to use them as a distribution format to still use them as an installation format. As an installation format they overlap with OS-level metadata, but that OS-level metadata has always been completely unavailable to Python programs so a little duplication has to be put up with. And anyway, the packaging systems can manage the system integrity well enough to keep that information in sync. Even though eggs overlap, they don't have to compete. > However, when running "python setup.py install" you are in fact > installing from source, so there's no need to wrap things up > again. > > The distutils default of actually installing things in the > standard Python is good, has worked for years and should continue > to do so. > > The extra information needed by the dependency checking can > easily be added to the package directory of the installed package > or stored elsewhere in a repository of installed packages or as > separate egg-info directory if we want to stick with setuptools' > way of using the path name for getting meta-information on a > package. Phillip can clarify this more, but I believe he's planning on Python 2.5 setuptools to install similar to distutils, but with a sibling .egg-info directory. There's already an option to do this, it's just a matter of whether it will be the default. A package with a sibling .egg-info directory is a "real" egg, but that it's a real egg probably highlights that eggness can be a bit confusing. > Placing the egg-files into the system as ZIP files should > be an option, e.g. as separate "install_egg" command, > not the default. I would prefer this too; even though Phillip has fixed the traceback problems for 2.5 I personally just prefer files I can view in other tools as well (my text editor doesn't like zip files, for instance). I typically make this change in distutils.cfg for my own systems. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
On 4/20/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > 1. don't load packages out of .zip files. It's not that bad if >software on the user's disk occupies multiple files, as long as >there is a convenient way to get rid of them at once. >Many problems go away if you just say no to zipimport. You forget that importing from a zip file is often much faster than importing from the filesystem. That's why zipimport was added in the first place. > 2. standardize on file names, not API. If I want to deploy >read-only data files, I put them into /usr/share. If I need >read-write files, I put them into /var. What about Windows? Putting data files in the same directory as source files solves a lot of problems of making the data follow the source no matter how/where it is installed (or if it's not installed at all, like when running code straight out of svn). Anyway, perhaps it's a matter of choice. It's clear to me that many developers prefer to do it this way. You don't. This is an area that has enough external constraints that I'm uncomfortable telling developers they can't do it that way. A standard API to access resources by name (with perhaps a registry for defining additional ways to find them) makes a lot of sense to me, and I don't think we're exactly inventing something novel here. [...] > 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. I consider this approach > flawed: once I leave the realm of KDE programs, this all stops > working. It is the operating system's job to provide unified > access to storage, not the programming language's or the job > of a library. I don't see it that way. All operating system access is mediated via the Python library anyway; and in many cases the Python library provides additional abstractions over what the operating system natively provides (e.g. many APIs in the os and os.path modules). 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
Ronald Oussoren wrote: > As far as I understand the issues they compete up to a point, but should > also make it easier to create platform packages that contain proper the > proper dependencies because those are part of machine-readable meta-data > instead of being written down in readme files. Oddly enough that was > also the objection from one linux distribution maintainer: somehow his > opinion was that the author of a package couldn't possibly know the > right depedencies for it. What he can't possibly know is the *name* of the package he depends on. For example, a distutils package might be called 'setuptools', so developers of additional packages might depend on 'setuptools'. However, on Debian, the dependency should be different: The package should depend on either 'python-setuptools' or 'python2.3-setuptools', depending on details which are off-topic here. > As for platform packages: not all platforms have useable packaging systems. > MacOSX is one example of those, the system packager is an installer and > doesn't include an uninstaller. Eggs make it a lot easier to manage python > software in such an environment (and please don't point me to Fink or > DarwinPorts on OSX, those have serious problems of their own). Isn't uninstallation just a matter of deleting a directory? If I know that I want to uninstall the Python package 'foo', I just delete its directory. Now, with setuptools, I might have multiple versions installed, so I have to chose (in Finder) which of them I want to delete. 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). >> Package >> authors will refuse to produce them, putting the burden of package >> maintenance (what packages are installed, what are their dependencies, >> when should I remove a package) onto the the end user/system >> administrator. > > Philip has added specific support for them: it is possible to install > packages in the tradition way but with some additional files that tell > setuptools about installed packages. As a system administrator, I don't *want* to learn how to install Python packages. I know how to install RPMs (or MSIs, or whatever system I manage); this should be good enough. If "this Python junk" comes with its own installer procedure, I will hate it. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
Ian Bicking wrote: > And now for a little pushback the other way -- as of this January > TurboGears has served up 100,000 egg files (I'm not sure what the window > for all those downloads is, but it hasn't been very long). Has it > occurred to you that they know something you don't about distribution? oh, effbot.org is shipping lots of packages too. 100,000 may sound a lot to you, but there are surprisingly many python users out there these days... (if I had a $ for every download, etc, etc). > ElementTree would be among those egg files, so you should also consider > how many people *haven't* asked you about problems related to the > installation process. as you may have noticed, I tend to hang out on the TurboGears list, so yes, I'm well aware of their use of eggs. a couple of observations: - turbogears is hosting all eggs on their own site. - 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. - people keep reporting download problems and compatibility problems. it's not obvious to me that they hadn't been better off if they'd just shipped everything in a good old tarball... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
Guido van Rossum wrote: > Anyway, perhaps it's a matter of choice. It's clear to me that many > developers prefer to do it this way. You don't. This is an area that > has enough external constraints that I'm uncomfortable telling > developers they can't do it that way. Hence my -0. I see the practical need for it, and practicality beats purity, but I still would like to see it done in what I think is the right way. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
Greg Ewing wrote: >> The "resources" name is actually quite a common meme; > > I believe it goes back to the original Macintosh, which > was the first and only computer in the world to have files > with something called a "resource fork". The resource fork > contained pieces of data called "resources". I can believe that history. Still, I thought a resource is something you can exhaust; the fork should have been named "data fork" or just "second fork". > Then Microsoft stole the name, and before you knew, > everyone was using it. It's all been downhill from > there. :-) Right. I'm not asking that the name is changed in setuptools - I'm just complaining about the state of the world, and showing my lack of intuition for the English language. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
Fredrik Lundh 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. I don't think setuptools version requirements are enough to ensure the integrity of all pieces of a complex system will work together. Figuring out a self-consistent set of packages to work together is something that is rather independent of any particular package, and Setuptools doesn't have a facility for that. But it does provide the tools to build that kind of facility, and egg-based installations provide the sufficient metadata to report on what has been built. So I think it is a step in the right direction. Integrating packages from a wide variety of sources is hard. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
Bob Ippolito wrote: >> 'There are several binary formats that embody eggs, but the most common >> is '.egg' zipfile format, because it's a convenient one for distributing >> projects.' >> >> '.egg files are a "zero installation" format for a Python package;' > > single modules are also such a "zero installation" format too. So what? > > You're simply reading things between the lines that aren't there. How > about you describe exactly what parts of the documentation that lead you > to believe that eggs are designed to compete with solutions like > rpm/msi/deb so that it can be clarified? It's not just the documentation: I firmly believe that many people consider .egg files to be a distribution and package management format. People have commented that some systems (e.g. OSX) doesn't have a usable native packager, so setuptools fills a need here. This shows that people do believe that .egg files are to OSX what .deb files are to Debian. As .egg files work on Debian, too, it is natural that they compete with .deb. Phillip Eby once said (IIRC) that he doesn't want package authors to learn all the different bdist_* commands (which also require access to the target systems sometimes), and that they their life gets easier as they now only have to ship the "native" Python binary packages, namely .egg files. In this view, rpm/msi/deb have no place anymore, and are obsolete. 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. So if this attitude (Python Eggs are the preferred binary distribution format) is wrong, it is the attitude that has to change first. Changes to the documentation follow from that. If the attitude is right, I'll have to accept that I have a minority opinion. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
Ian Bicking wrote: > I don't think setuptools version requirements are enough to ensure the > integrity of all pieces of a complex system will work together. > Figuring out a self-consistent set of packages to work together is > something that is rather independent of any particular package, and > Setuptools doesn't have a facility for that. But it does provide the > tools to build that kind of facility, and egg-based installations > provide the sufficient metadata to report on what has been built. So I > think it is a step in the right direction. Integrating packages from a > wide variety of sources is hard. Indeed. Microsoft also thought that side-by-side installation of .NET assemblies will solve all versioning problems, as you can have as many versions installed simultaneously as you want to. It turns out that they also where wrong: at best, side-by-side installation can *help* to solve versioning problems. It might also contribute to increase them, as people stop worrying about backwards compatibility, trusting that side-by-side installation can replace proper engineering. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
Ian Bicking wrote: > Fredrik Lundh wrote: >> [EMAIL PROTECTED] wrote: >>> Maybe they know something we don't. >> oh, please. it's not like people like myself and MAL don't know anything >> about package distribution... >> >> (why is it that people who *don't* distribute stuff are a lot more im- >> pressed by a magic tool than people who've spent the last decade >> distributing stuff ? has it ever occurred to you that we know some- >> thing that you don't ?) > > There's many people packaging and distributing code with setuptools, but > very few of them are on this list. Setuptools has gotten quite a lot of > use and a lot of pushback from people, but only from the people who have > been using it. People who have complained about Setuptools without > using it have had little influence, because most of their suggestions > are only resolvable by having Setuptools simply cease to exist, which is > not very constructive. Ian, this is simply not true. The folks who have complained had good reasons to do so and most of them have been in the distribution field for a long time. There have been several attempts to get setuptools back on the track with Python standards, but all requests were ignored. Only after endless discussions, Phillip added some weird --long-option-name-that-no-one-can-remember to the setuptools "install" command that restores the standard distutils behavior which should be the default anyway. The suggestions that were made were constructive. Just look at the distutils-sig archive. Only very few of the suggestions were taken into account. Instead, setuptools fans insisted on their right to have everything "just work" in their sense of the word. Most of them probably don't even know what the distutils or Python standards are for installing packages, where the motivation to have zip imports came from and have only ever seen and used the setuptools way. It's natural to then see any suggestion to change their view on things as being counter-productive or hostile. The people who try to get setuptools back on track receive the same kind of hostility that you perceive to be getting from them. This is the reason I stopped discussing these things on distutils-sig. The two camps need to come together again, but that will require understanding some of the history and standards that we've had in Python ever since Python packages were introduced. It will also require the setuptools folks to get some feeling of respect for those who have worked in the field for years. You may not know it, but having worked with distutils for a long time, I have great respect for Phillip's work - it's just that I find some of his design decisions wrong, since they don't follow the standards. > But even then, I've seen Phillip make many > changes to Setuptools based on feedback from people who just wanted > Setuptools to get out of their way; but again, you have to at least be > using it to give this kind of feedback. > > And somewhat tangential, but related to much of this discussion: if > Phillip had been doing developments for distutils all this time instead > of making a package that was separately installable under a different > name, Setuptools would never have gotten the use and feedback that is > has so far received. We could turn this into a discussion about how to > handle updates to the standard library, but given the constraints I > think Setuptools was developed in the best way possible. If development > had happened here on python-dev and released to the large community only > with the next Python release, Setuptools would be far inferior to its > current state. I think that the project would have been even better than it is now, had it started out in a different way, namely Python standards compliant. But like Anthony said: we're still in alpha, so there's still some hope that we can get those few warts removed from setuptools and a true integration in place for everybody to enjoy. > And now for a little pushback the other way -- as of this January > TurboGears has served up 100,000 egg files (I'm not sure what the window > for all those downloads is, but it hasn't been very long). Has it > occurred to you that they know something you don't about distribution? > ElementTree would be among those egg files, so you should also consider > how many people *haven't* asked you about problems related to the > installation process. I wonder why people always seem to imply that installing packages has never worked before there was setuptools. There's really nothing wrong with the standard distutils two step process: 1. download and unzip the source file 2. run "python setup.py install" I've been publishing the mx Tools since 1997. Back then we only had the old Makefile.pre.in mechanism and still most people managed to get the tools working (step 2 then being: "make -f Makefile.pre.in boot; make; make install") without having to ask for help. Since I've started using distuti
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
At 10:59 PM 4/20/2006 +0200, Martin v. Löwis wrote: >Bob Ippolito wrote: > > They DO NOT compete any more than source packages do. eggs are packages > > plus metadata, nothing more. What eggs do and what rpm/msi/deb does are > > orthogonal. It's entirely reasonable that in the future rpm/msi/deb > > will simply be a delivery mechanism for eggs. > >That might be your view, but it apparently isn't the view of the >inventor(s). For the record, Bob *is* the co-inventor of eggs; he was the only person who responded to my call on the distutils-sig for the creation of a format for distribution of plugins, and it is largely due to his efforts that the egg runtime exists in the first place. In addition, it was he who convinced me that they would be good for installing arbitrary Python libraries, not just plugins for extensible applications. It's true that a lot of our initial discussions and even some of the documentation seem to blur the line a bit as to what eggs are. Clarity often takes time to develop. In fact, it wasn't until the Debian packaging flap on distutils-sig last fall that we were forced to clarify our thoughts enough to realize that distribution packaging was always just a means to an end - a way of reifying the idea of a library or plugin as a self-contained and self-describing unit. Distribution and installation are certainly a part of the overall picture, but the essential nature of eggs is to make *project releases* truly first-class objects in Python. A lot of your arguments (and some of MAL's) against eggs as "unnecessary" have been based on the (incorrect) theory that Python packages (importable unit) constitute the appropriate grain of modularity for system packages (distributable unit). But ever since the distutils existed, it has been clear that distribution units are not a 1:1 mapping with packages in the Python sense of the word. The stdlib itself gives lie to that concept, since there are many packages in it, yet it is distributed as a single project release. Eggs, however represent project releases as tangible objects: the "1.1 release of FooBar" is a thing that can be installed, put on sys.path, searched for, depended on, and so forth. This is a valuable concept to have access to from Python code, independent of how these project releases actually end up on a system, or how they are physically arranged when they get there. It is intimately related to delivery and installation, of course. But to claim that they're competing with system packages is to miss the point. If you run "bdist_rpm" on a setuptools-based setup script, for example, you will get an RPM that looks just like any other RPM for a Python package, merely with the addition of an .egg-info directory that contains introspectable data. (And the same thing happens for bdist_wininst and any other bdist_* tool that uses "setup.py install --root" to build its target image.) In other words, if the delivery and installation part is handled by some other tool, then only the true "egg" remains: a project release as a discoverable and introspectable unit. That's not to say that the eggs didn't *originate* as a way to solve all of the problems in one fell swoop, but the point is that eggs do *NOT* compete with existing system packaging tools within their domain of competence. What I'm opposed to in making setuptools install things the distutils way by default is that there is no easy path to clean upgrade or installation in the absence of a system packaging tool like RPM or deb or what-have-you. I am not opposed to doing the "classic" style of installation by default *forever*, but only until setuptools can handle uninstallation and upgrades in that format. Right now, it's a lot easier to uninstall things if they are all in one directory. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
At 11:26 PM 4/20/2006 +0200, 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, which > > was the first and only computer in the world to have files > > with something called a "resource fork". The resource fork > > contained pieces of data called "resources". > >I can believe that history. Still, I thought a resource >is something you can exhaust; the fork should have been >named "data fork" or just "second fork". I suspect that the distinction is that "data" sounds too much like something belonging to the *user* of the program, whereas "resources" can reasonably be construed to be something that belongs to the program itself. 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. Interestingly enough, there is another "resource" tool for Python out there, that actually works by converting resource files to strings in .py files, so that you can then just import them. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
>>And now for a little pushback the other way -- as of this January >>TurboGears has served up 100,000 egg files (I'm not sure what the window >>for all those downloads is, but it hasn't been very long). Has it >>occurred to you that they know something you don't about distribution? >>ElementTree would be among those egg files, so you should also consider >>how many people *haven't* asked you about problems related to the >>installation process. Really, I just shouldn't have made this argument; the discussion was going back towards a calmer and more constructive discussion and I pushed it the other way. Sorry. Please ignore. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
On 4/20/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > I thought a resource > is something you can exhaust; the fork should have been > named "data fork" or just "second fork". Hmm... I don't think that the English word "resource" necessarily implies that it can be exhausted. In US businesses, people are often also referred to as resources. I've come to think of it as simply "what you need". The definition at http://www.answers.com/resource has this: """ 1. Something that can be used for support or help: The local library is a valuable resource. 2. An available supply that can be drawn on when needed. Often used in the plural. 3. The ability to deal with a difficult or troublesome situation effectively; initiative: a person of resource. 4. Means that can be used to cope with a difficult situation. Often used in the plural: needed all my intellectual resources for the exam. 5. 1. resources The total means available for economic and political development, such as mineral wealth, labor force, and armaments. 2. resources The total means available to a company for increasing production or profit, including plant, labor, and raw material; assets. 3. Such means considered individually. """ #1 and #2 especially explain the usage we're considering. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
Guido van Rossum wrote: > On 4/20/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> 1. don't load packages out of .zip files. It's not that bad if >>software on the user's disk occupies multiple files, as long as >>there is a convenient way to get rid of them at once. >>Many problems go away if you just say no to zipimport. > > You forget that importing from a zip file is often much faster than > importing from the filesystem. That's why zipimport was added in the > first place. This is true if you only have a single ZIP file, e.g. python24.zip on sys.path. It is not if you have dozens of ZIP files on sys.path, since you have to take the initial scan time plus the memory for caching the ZIP file contents into account. Each ZIp file adds to Python startup time, since the ZIP files on sys.path are scanned for every Python startup. Here's an example of the effect of having just 20 eggs on sys.path: tmp/eggs> time python -S -c '0' 0.014u 0.006s 0:00.02 50.0% 0+0k 0+0io 0pf+0w tmp/eggs> unsetenv PYTHONPATH tmp/eggs> time python -S -c '0' 0.006u 0.003s 0:00.01 0.0% 0+0k 0+0io 0pf+0w (Reference: http://mail.python.org/pipermail/distutils-sig/2005-December/005739.html) Startup time effectively doubles, even if you don't use any of the installed eggs in your script. The main reason for adding zip imports was to simplify deploying (complete) applications to users, e.g. have the complete Python stdlib in one file. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 20 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
Phillip J. Eby wrote: > What I'm opposed to in making setuptools install things the distutils way > by default is that there is no easy path to clean upgrade or installation > in the absence of a system packaging tool like RPM or deb or > what-have-you. I am not opposed to doing the "classic" style of > installation by default *forever*, but only until setuptools can handle > uninstallation and upgrades in that format. Right now, it's a lot easier > to uninstall things if they are all in one directory. If that's all it takes, have a look at the uninstall implementation in mxSetup.py (e.g. from egenix-mx-base). This will work with any half decent distutils setup.py file, since it uses the original install process as basis for finding the files to uninstall. (Not my idea: credits go to Thomas Heller.) BTW, if there's interest, I can look into porting the stuff in mxSetup.py into stock distutils. That'll give it uninstall, some autoconf and support for building Unix C libs as part of the process (plus a bunch of other things). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 21 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
On 4/20/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > I wonder why people always seem to imply that installing > packages has never worked before there was setuptools. > > There's really nothing wrong with the standard distutils > two step process: > > 1. download and unzip the source file > > 2. run "python setup.py install" [I'm very reluctant to join in this discussion, as (a) I have no packaging experience (being a pure "user" of other people's packages, and (b) I have no personal need for the fancy features in setuptools. Apologies in advance, therefore, if I misrepresent anything.] As a Windows user, I generally have 2 problems with this process. 1. There's no uninstall. 2. There is no list of what is installed. (Unless I manage these 2 manually, but that's always an option). However, if I do "python setup.py bdist_wininst" all is rosy again. The standard "Add/Remove Programs" listing becomes both my uninstaller and my list of installed packages. Initially, eggs were a problem for me, as they didn't conform to this standard. This was, as I understand it, because the package layout installed by distutils didn't include the metadata needed for the setuptools features like version checking. So, packages which used those features *couldn't* be distributed as bdist_wininst format. However, Philip addressed this. The new format with a .egg-info directory allows for egg metadata. This is automatically used in commands like bdist_wininst under setuptools. I'm left (I believe) with a couple of issues, though. 1. Only packages which import setuptools in their setup.py will generate egg metadata. So, for example, PIL doesn't have egg metadata by default. 2. Distributors will supply .egg files rather than bdist_wininst installers (this is already happening). (1) is an issue for packages which "require" specific versions of other packages. For example, turbogears requires elementtree - but the standard elementtree installer distributed by Fredrik doesn't include egg metadata, so it "doesn't count". I either need to install the egg as well (which doesn't go in Add/Remove Programs), or build my own elementtree installer (not always easy, as C compilers aren't available on every Windows box, for example). (2) is an issue as it means I'll end up less likely to be able to get "native" installers. It's possible that (1) can be solved by making *all* distutils installs create egg metadata. That may be what's meant by "integrating setuptools functionality into distutils". If so, I'd support this. I'm not sure how to solve (2). I have no interest in, or use for, ez_setup. I prefer to manage my version issues manually, and I don't like tools that automatically download stuff off the internet (no matter how much it's an on-request only process). That's fine - it's my choice. But if I become a minority, the demand for bdist_wininst installers diminishes to the point that no-one produces them. And *that's* a step backwards. A key benefit of distutils for me was that a standard Windows binary installer format became common. I'd hate to lose that. (And I don't feel that eggs are a comparable option - unless a complete package management solution gets added). Maybe a .egg -> .bdist_wininst converter is feasible. I don't know. If so, that may be a way out. > BTW: thanks to Greg Ward for creating distutils in the > first place :-) Agreed. And thanks to Philip for going the next step. But let's keep working to ensure that in solving a new set of problems, setuptools doesn't make things harder for people who never *had* that set of problems... Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
At 11:49 PM 4/20/2006 +0100, Paul Moore wrote: >It's possible that (1) can be solved by making *all* distutils >installs create egg metadata. This is already planned to be addressed in Python 2.5, via the install_egg_info added to the distutils. The implementation is already in the trunk, but not documented. (Guido approved the patch, for anybody concerned about "who said" it should go in.) It installs a standard distutils PKG-INFO file as Project-Version.egg-info alongside the installed package(s). >A key benefit of distutils for me was that >a standard Windows binary installer format became common. I'd hate to >lose that. (And I don't feel that eggs are a comparable option - >unless a complete package management solution gets added). Side note: The "nest" command framework is supposed to be that solution for platforms without system package managers, i.e. full list/delete/etc. support. Of course, that's a command-line tool, but it should be a lot easier to build a GUI on top of nest than on top of easy_install. >Maybe a .egg -> .bdist_wininst converter is feasible. I don't know. If >so, that may be a way out. easy_install contains the reverse: a bdist_wininst -> .egg converter. Going the other way should actually be easier, if somebody wants to take a whack at it. Might make a good test case for the not-yet-written "formats overview" document on eggs, actually. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Stream codecs and _multibytecodec
While merging the trunk changes into the p3yk branch, I discovered what I think is a bug in the stream codecs. It's easily reproduced in the trunk: in Lib/codecs.py, make the 'Codec' class new-style. Then, suddenly, test_codecs will crash with an exception like this: ==ERROR: test_basics (test.test_codecs.BasicUnicodeTest)--Traceback (most recent call last): File "/home/thomas/python/python/trunk/Lib/test/test_codecs.py", line 1089, in test_basics writer = codecs.getwriter(encoding)(q) File "/home/thomas/python/python/trunk/Lib/codecs.py", line 296, in __init__ self.stream = streamTypeError: readonly attributeLooking at the class, it's hard to tell how it's suddenly a read-only attribute, until you figure out which codec it breaks with: big5. Which is defined in encodings.big5, as a subclass of codecs.Codec, _multibytecodec.MultibyteStreamWriter and codecs.StreamWriter. And _multibytecodec.MultibyteStreamWriter is a new-style class (as it's defined in C) with a read-only 'stream' attribute. The conflicting attribute is silently masked by Python, since classic classes ignore two-thirds of the descriptor protocol (setting and deleting), but it jumps right out when all classes become new-style. I'm not sure whether this attribute conflict is on purpose or not, but since it will break in the future, I suggest it gets fixed. It *looks* like renaming the _MultibyteStreamWriter attribute is the easiest solution, but I don't know which API has precedence. (One of the two was added fairly recently, at least, since it didn't break in the p3yk branch until I merged in the last few months' worth of changes :) -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python 2.5alpha and naming schemes
I read the python 2.5alpha release notes and found that some module and class names should not make it into the official release. For example, the name of the ctypes module is ok because the module is only of special interest, but calls like py_object or create_string_buffer should definetly be changed to something more python-like. Module names like hashlib are not python-like too (too c/lowlevel-like). Please think about it... Dennis ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] extended bitwise operations
I often experiment with touring machine algorithms and play around with alternative arithmetics. I'd like to do that with python but it offers only the standard bitwise operators. They're fine if one wants to do manipulations on the full integer. However, I'd like to have direct (single) bit access to be able to implement own rules, like how to deal with the carry. There is a very nice and very very small implementation of a BitArray that can do this. It is under the LGPL. However, it provides only a handful of functions. Possibly you like to implement an own version as a python module (I'd rather like to see a default syntax that can restrict the implemented bitwise operators to single bits or groups of bits.) Please have a look at bitarray.c: http://michael.dipperstein.com/bitlibs/bitlibs.html There are several other versions on the net. This one is more comfortable: http://www.koders.com/c/fid7F57E63EAE4B6028AAF3DCDB6414AD240CFB6CDD.aspx Thanks, Dennis ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] windows buildbot failures
Le 17 avr. 06 à 20:59, Martin v. Löwis a écrit :
>> OTOH, we could just as well check in an executable that
>> does all that, e.g. like the one in
>
> I did something like this: I checked the source of a
> kill_python.exe application which looks at all running processes
> and tries to kill python_d.exe. After several rounds of
> experimentation, this now was able to unstick Trent's build
> slave.
Sorry I'm late, but something like "os.popen('taskkill.exe /F /IM
python_d.exe')" would have worked; we use this at work.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
At 11:53 PM 4/20/2006 +0200, M.-A. Lemburg wrote: >Only after endless discussions, Phillip added some weird >--long-option-name-that-no-one-can-remember to the setuptools >"install" command that restores the standard distutils behavior >which should be the default anyway. And later, I also made it the default behavior for installation with --root, without any further prompting from you or anyone, in fact. >The suggestions that were made were constructive. Just look >at the distutils-sig archive. Only very few of the suggestions >were taken into account. Actually, *all* of your suggestions were *taken into account*, by which I mean I have done all I can to understand them and to understand the concerns behind them -- as I do with all requests and feedback. Some, however, will be a long time coming in implementation, or are things I simply can't agree with. Those suggestions may or may not be "right" in some sense, but they are not right *for setuptools*. But I take all suggestions into account, and sometimes I find ways to implement them. When I say "no", it simply means, "I don't see how I can do that without breaking some other constraint." It has happened repeatedly, however, that a way of doing something occurs to me months after the request, and then it is added with little fanfare. Meanwhile, I'm always going to give a higher priority to the requests that are in strong alignment with the goals of setuptools, and come from: * developers actually using setuptools, * users who are installing packages that use setuptools, or * system packagers who would like to package things that use setuptools It also helps if they are things I can actually come up with a way to implement, without violating setuptools' goals. > Instead, setuptools fans insisted on >their right to have everything "just work" in their sense >of the word. Yeah, but they're not as bad as those Python fans with their crazy insistence on significant whitespace. ;) Seriously, do you really think this is a *bad* thing? >Most of them probably don't even know what the distutils >or Python standards are for installing packages, where the >motivation to have zip imports came from and have only >ever seen and used the setuptools way. Um, yeah, because Jim Fulton is such a newbie to Python, surely *he's* never had to use Makefile.pre.in to build exotic C exten... Oh, wait, never mind. :) >The two camps need to come together again, but that will require >understanding some of the history and standards that we've >had in Python ever since Python packages were introduced. >It will also require the setuptools folks to get some >feeling of respect for those who have worked in the field >for years. I'm sorry, but this is an example of the highly patronizing attitude you've been giving on the distutils-sig since day one. As it happens, I too remember the world before distutils. With due respect, Marc, not every Python developer is you or Fredrik or Jim. There are plenty of people with things to contribute to Python who find the distutils upsetting, confusing, or worse. When I started doing work for OSAF, I was very surprised to find out how many developers new to Python found the distutils not merely inconvenient (which was my personal perspective) but simply unusable. Some let forth streams of profanity at the mere *mention* of the distutils. So, please consider this: to experts such as you and I, the distutils may merely be inconvenient or tedious, something to throw together an mxSetup.py or zpkgutil or some such convenient utilities to handle all your personal distribution needs and avoid the repetition and tedium. And in fact, setuptools originally began as just such a few extensions for my personal use. But to Python newbies, the distutils is a confusing, broken, undocumented, arcane, archaic, unpredictable useless piece of , an embarrassment to Python, far worse than Java, and many many other things. And yes, those are all things that people have actually said to me. They really, really want things to Just Work, and they say so in so many words. So when I work on setuptools, I imagine those developers, and I try to imagine what they will think and what they will expect. To be frank, you haven't shown in our discussions that you respect or value *those* developers' perspective. You seem to believe that there are other things more important than making things Just Work for this audience. I don't know what those things are, but all I can say is, to me they don't exist. I just can't see it. Because all I can see is the frustration on the faces of developers who were enthusiastic about Python until they encountered the distutils. Distutils *is* great. It's also unusable for developers who have better things to do with their time. The two are not mutually exclusive, as Fredrik has often enough pointed out regarding other problems with Python's "public face". >You
Re: [Python-Dev] setuptools in 2.5.
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. 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. Fredrik also asked for a document, but I don't think it is this document; it wasn't clear to me what exactly he wanted documented. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] unrecognized command line option "-Wno-long-double"
Dear Python and Mac Community, I have just successfully built gcc version 4.1.0 for my Mac OS X 10.4.6. gcc -v Using built-in specs. Target: powerpc-apple-darwin8.6.0 Configured with: /usr/local/src/gcc-4.1.0/configure Thread model: posix gcc version 4.1.0 When I try to build Python 2.4.3, I get the following error below: gcc -c -fno-strict-aliasing -no-cpp-precomp -mno-fused-madd -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c gcc: unrecognized option '-no-cpp-precomp' gcc: unrecognized option '-no-cpp-precomp' cc1: error: unrecognized command line option "-Wno-long-double" make: *** [Modules/python.o] Error 1 Python make failed. What is the best solution for this unrecognized command line option? Thanks for your help in advance, Dean ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
Hello,
just one more datapoint to help Phillip change his mind on the default install
behavior and the monkeypatching: this is actually hurting adoption of
setuptools.
example: the matplotlib folks wanted to add *optional* setuptool support, but
this is impossible because simply importing setuptools has too much
side-effects. So instead, they ask the setuptool users to use
python -c "import setuptools; execfile('setup.py')" install
That's just too bad, and much more confusing than setup.py install_egg !
Oh, and don't get me wrong, I *love* eggs. They are great for many use cases,
even for a Debian user!
From the "user" point of view, they definitely belong in the stdlib, the
sooner, the better. They just need a little bit more polishing.
Phillip, thank you a lot for making this happen :-) I feel that the hostility
is
undeserved.
Baptiste
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
At 12:32 AM 4/21/2006 +0200, M.-A. Lemburg wrote: >Phillip J. Eby wrote: > > What I'm opposed to in making setuptools install things the distutils way > > by default is that there is no easy path to clean upgrade or installation > > in the absence of a system packaging tool like RPM or deb or > > what-have-you. I am not opposed to doing the "classic" style of > > installation by default *forever*, but only until setuptools can handle > > uninstallation and upgrades in that format. Right now, it's a lot easier > > to uninstall things if they are all in one directory. > >If that's all it takes, have a look at the uninstall implementation >in mxSetup.py (e.g. from egenix-mx-base). I have. As far as I can tell, it requires you to save the original setup.py, and for any dynamic considerations of that setup.py to still be in effect. What's actually needed is to save the list of outputs at *installation* time, so it's not practical to use your implementation for setuptools' purposes. I thought I'd explained this when you suggested this on the distutils-sig previously, but perhaps I forgot to. As well, there's another consideration for easy_install, which "virtualizes" the installation process for packages that don't use setuptools. 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. It's often hard to implement correctly in the first place, so this is probably why most tools that wrap distutils prefer to use --root instead of --record anyway... which means that there's even less incentive to write correct get_outputs() methods. >BTW, if there's interest, I can look into porting the stuff in >mxSetup.py into stock distutils. That'll give it uninstall, >some autoconf and support for building Unix C libs as part of >the process (plus a bunch of other things). I imagine quite a lot of those things would be useful, except that I have personally noticed some issues through these extensions not following distutils standards. (Oh, the irony! :)) Specifically, I have noticed that your autoconf command does not use the 'build' command as the basis for obtaining its default '--compiler', which caused me quite a bit of trouble when trying to easy_install some of your packages. At least your mx_build_ext command handles this correctly. In general, distutils commands take their defaults from either the "build" or "install" master commands, as this allows users to have a single place to configure default options. But I digress. I do think there are a lot of useful things in your work and it was on my list to steal as many of your ideas as possible as soon as I got to working on setuptools things that needed them. :) I certainly wouldn't object to them being in the distutils, though I'm likely to nitpick certain little things like the aforementioned compiler defaults. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
On Thu, 2006-04-20 at 23:53 +0200, M.-A. Lemburg wrote: > There's really nothing wrong with the standard distutils > two step process: > > 1. download and unzip the source file > > 2. run "python setup.py install" The only thing I'll add (other than put me in the "just make it work and tell me what to do" camp ;) is that I really want a simple way to say "do not install into the system Python, put everything over here and I will fiddle with my environment to make it work". I may be way out of date with the state of the art these days, but in the past, I've had a difficult time making this work for Mailman. For example, at various times we've had to distribute our own email package and Asian codecs packages. The only way I've gotten things to work is by specifying --install-lib --install-data and --install-purelib switches, which was pretty difficult (IIRC) to figure out. Again, maybe there's an easy way to do this with modern distutils, but I just want to make sure this is a use case that's on the radar. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] extended bitwise operations
Dennis Heuer <[EMAIL PROTECTED]> wrote: > I often experiment with touring machine algorithms and play around with > alternative arithmetics. I'd like to do that with python but it offers > only the standard bitwise operators. They're fine if one wants to do > manipulations on the full integer. However, I'd like to have direct > (single) bit access to be able to implement own rules, like how to deal > with the carry. There is a very nice and very very small implementation > of a BitArray that can do this. It is under the LGPL. However, it > provides only a handful of functions. Possibly you like to implement an > own version as a python module (I'd rather like to see a default syntax > that can restrict the implemented bitwise operators to single bits or > groups of bits.) Please have a look at bitarray.c: Bitwise access to integers has been discussed in python-dev and python-list for quite a while, each time being refused for one reason or another (though it has been a while since someone has brought it up here). Since bit arrays are arguably trivial to implement in Python (I once did it in something like 20 lines), and because there hasn't been a significant push from the Python user community, I can't help but be -1. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools in 2.5.
At 07:33 PM 4/20/2006 -0400, Barry Warsaw wrote: >The only thing I'll add (other than put me in the "just make it work and >tell me what to do" camp ;) is that I really want a simple way to say >"do not install into the system Python, put everything over here and I >will fiddle with my environment to make it work". > >I may be way out of date with the state of the art these days, but in >the past, I've had a difficult time making this work for Mailman. For >example, at various times we've had to distribute our own email package >and Asian codecs packages. The only way I've gotten things to work is >by specifying --install-lib --install-data and --install-purelib >switches, which was pretty difficult (IIRC) to figure out. I'm surprised you needed --install-purelib; it seems like install-lib should have been sufficient. 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. >Again, maybe there's an easy way to do this with modern distutils, but I >just want to make sure this is a use case that's on the radar. In the easy_install case, "easy_install -d wherever" puts everything (and I do mean *everything*, including scripts) under the 'wherever' directory. If you want scripts to go someplace different, there's a separate option. But if you don't specify these things, easy_install gets its defaults from those defined for distutils, specifically the --install-lib and --install-scripts options of the "install" command. However, easy_install will gripe if the "-d wherever" isn't in PYTHONPATH and isn't site-packages, and you aren't saying you don't need it to be importable. If you promise to make sure the installed packages will be on sys.path when you want to import them, you use -m or --multi-version and easy_install will happily put the packages anywhere you like and leave it to you to get them on sys.path. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unrecognized command line option "-Wno-long-double"
On Wed, Apr 19, 2006, Dean N. Williams wrote: > > When I try to build Python 2.4.3, I get the following error below: Please do not spam multiple lists. Please read this URL before you ask for further help: http://www.catb.org/~esr/faqs/smart-questions.html -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Argue for your limitations, and sure enough they're yours." --Richard Bach ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 2.5alpha and naming schemes
> 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stream codecs and _multibytecodec
On 4/21/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > While merging the trunk changes into the p3yk branch, I discovered what I > think is a bug in the stream codecs. It's easily reproduced in the trunk: in > Lib/codecs.py, make the 'Codec' class new-style. Then, suddenly, test_codecs > will crash with an exception like this: [snip] > I'm not sure whether this attribute conflict is on purpose or not, but since > it will break in the future, I suggest it gets fixed. It *looks* like > renaming the _MultibyteStreamWriter attribute is the easiest solution, but I > don't know which API has precedence. The readonly attribute "stream" of _MultibyteStreamWriter is exactly equivalent to codecs.StreamWriter's and it can't be removed to work correctly. I intended to override all methods of StreamWriters. The only reason why it inherits from codecs.StreamWriter is not to break isinstance(x, StreamWriter) checks and nothing from StreamWriter is used at all. I'll verify and fix it in p3yk branch soon. Thank you for the inspection! Hye-Shik ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
