Re: [Python-Dev] Dropping __init__.py requirement for subpackages
On 4/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 4/26/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > Of course, I only consider *my* reasons to be valid, and mine weren't > > knee-jerk or tool-related. I don't think Python should be going "Oh, what > > you wanted wasn't possible, but I think I know what you wanted, let me do it > > for you", first of all because it's not very Pythonic, and second of all > > because it doesn't lower the learning curve, it just delays some upward > > motion a little (meaning the curve may become steeper, later.) A clear > > warning, on the other hand, can be a helpful nudge towards the 'a-HA' > > moment. > > That still sounds like old-timer reasoning. Long ago we were very > close to defining a package as "a directory" -- with none of this > "must contain __init__.py or another *.py file" nonsense. IIRC the > decision to make __init__.py mandatory faced opposition too, since > people were already doing packages with just directories (which is > quite clean and elegant, and that's also how it was in Java), but I > added it after seeing a few newbies tear out their hair. OK. After due consideration, I'm happy to accept the change. (Call that +0, it doesn't bother me much personally either way). Although reading the above paragraph, I get the impression that you are saying that __init__.py was originally added to help newbies, and yet you are now saying the exact opposite. I'll leave you to resolve that particular contradiction, though... FWIW, I still have every confidence in your judgement about features. However, I'd have to say that your timing sucks :-) Your initial message read to me as "Quick! I'm about to get lynched here - can I have the OK to shove this change in before a2 goes out?" (OK, 2.5 isn't feature frozen until a3, so maybe you only meant a3, but you clearly wanted a quick response). So it's hard to expect anything other than immediate knee-jerk responses. And those are usually driven by personal experience (implying less consideration of newbie mistakes from this type of audience) and unfocused fear of breakage. 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] Dropping __init__.py requirement for subpackages
On 4/27/06, Paul Moore <[EMAIL PROTECTED]> wrote: > However, I'd have to say that your timing sucks :-) Your initial > message read to me as "Quick! I'm about to get lynched here - can I > have the OK to shove this change in before a2 goes out?" And this just proves that my response wasn't anywhere near as considered as I thought. You explicitly said 2.6, which I'd forgotten. I have no problem with going with your instinct in 2.6. But I do believe that there may be more breakage than you have considered (PEP 302 experience talking here :-)) so get it in early rather than late! Of course this is all a bit moot now, as the decision seems to have been made. Sigh. 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] Dropping __init__.py requirement for subpackages
On Thursday 27 April 2006 17:47, Paul Moore wrote: > FWIW, I still have every confidence in your judgement about > features. However, I'd have to say that your timing sucks :-) Your > initial message read to me as "Quick! I'm about to get lynched here > - can I have the OK to shove this change in before a2 goes out?" > (OK, 2.5 isn't feature frozen until a3, so maybe you only meant a3, > but you clearly wanted a quick response). Feature freeze is the day we release beta1. New features go in until then - after that, not without approval and a general concensus that the changes have a substantial cost/benefit for breaking the feature freeze. Or if Guido gets Google developers parading him in effigy around the office and needs to get them off his back. 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] Dropping __init__.py requirement for subpackages
Guido van Rossum python.org> writes:
> The requirement that a directlry must contain an __init__.py file
> before it is considered a valid package has always been controversial.
> It's designed to prevent the existence of a directory with a common
> name like "time" or "string" from preventing fundamental imports to
> work. But the feature often trips newbie Python programmers (of which
> there are a lot at Google, at our current growth rate we're probably
> training more new Python programmers than any other organization
> worldwide .
Might I suggest an alternative?
I too find it cumbersome to have to litter my directory tree with __init__.py
iles. However, rather than making modules be implicit ("Explicit is better
than implicit"), I would rather see a more powerful syntax for declaring
modules.
Specifically, what I would like to see is a way for a top-level __init__.py to
explicitly list which subdirectories are modules. Rather than spreading that
information over a bunch of different __init__.py files, I would much rather
have the information be centralized in a single text file for the whole
package.
Just as we have an __all__ variable that indicates which symbols are to be
exported, we could have a '__submodules__' array which explicitly calls out
the list of submodule directory names. Or perhaps more simply, just have
some code in the top-level __init__.py that creates (but does not load)
the module objects for the various sub-modules.
The presence of "__init__.py" could perhaps also indicate the root of
a *standalone* module tree; submodules that don't have their own
__init__.py, but which are declared indirectly via an ancestor are assumed
by convention to be 'component' modules which are not intended to
operate outside of their parent. (In other words, the presence of the
__init__.py signals that that tree is separately exportable.)
I'm sure that someone who is familiar with the import machinery could
whip up something like this in a matter of minutes.
As far as the "compatibility with tools" argument goes, I say, break em :)
Those tool programmers need a hobby anyway :)
-- 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] binary trees. Review obmalloc.c
Josiah Carlson wrote: > "Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> wrote: > >> Josiah Carlson wrote: >> >>> There exists various C and Python implementations of both AVL and >>> Red-Black trees. For users of Python who want to use AVL and/or >>> Red-Black trees, I would urge them to use the Python implementations. >>> In the case of *needing* the speed of a C extension, there already >>> exists a CPython extension module for AVL trees: >>> http://www.python.org/pypi/pyavl/1.1 >>> >>> I would suggest you look through some suggested SoC projects in the >>> wiki: >>> http://wiki.python.org/moin/SummerOfCode >>> >>> - Josiah >>> >>> >>> >> Thanks for the answer! >> >> I already saw pyavl-1.1. But for this reason I would like to see the module >> in a standard package python. Functionality for pyavl and dict to compare >> difficultly. Functionality of my module will differ from functionality dict >> in the best party. I have lead some tests on for work with different types >> both for a package pyavl-1.1, and for the prototype of own module. The >> script >> of check is resulted in attached a file avl-timeit.py In files >> timeit-result-*-*.txt results of this test. The first in the name of a file >> means quantity of the added elements, the second - argument of a method >> timeit. There it is visible, that in spite of the fact that the module >> xtree >> is more combined in comparison with pyavl the module (for everyone again >> inserted pair [the key, value], is created two elements: python object - >> pair, >> and an internal element of a tree), even in this case it works a little bit >> more quickly. Besides the module pyavl is unstable for work in multithread >> appendices (look the attached file module-avl-is-thread-unsafe.py). >> > > I'm not concerned about the speed of the external AVL module, and I'm > not concerned about the speed of trees in Python; so far people have > found that dictionaries are generally sufficient. More specifically, > while new lambda syntaxes are presented almost weekly, I haven't heard > anyone complain about Python's lack of a tree module in months. As a > result, I don't find the possible addition of any tree structure to the > collections module as being a generally compelling addition. > The object dict is irreplaceable in most cases, it so. I do not assume, that binary trees can sometime replace standard `dict' object. Sorting of the list also is and will be irreplaceable function. But there is a number of problems which can be rather easily solved by means of binary trees. Most likely for them there will be an alternative. But, as a rule, it is less obvious to the programmer. And most likely realization will be not so fast. Probably that nobody mentioned necessity of binary trees. In my opinion it is not a reason in an estimation of necessity of the given type. To take for example PHP. The array and the dictionary there is realized as the list. There is no even a hint on hash object. Those users to whom was necessary hash already have chosen perl/python/ruby/etc. The similar situation can arise and concerning binary trees. > Again, I believe that the existance of 3rd party extension modules which > implement AVL and red-black trees, regardless of their lack of thread > safety, slower than your module by a constant, or lack of particular > functionality to be basically immaterial to this discussion. In my mind, > there are only two relevant items to this discussion: > > 1. Is having a tree implementation (AVL or Red-Black) important, and if > so, is it important enough to include in the collections module? > 2. Is a tree implementation important enough for google to pay for its > inclusion, given that there exists pyavl and a collectionsmodule.c patch > for a red-black tree implementation? > > Then again, you already have your own implementation of a tree module, > and it seems as though you would like to be paid for this already-done > work. I don't know how google feels about such things, but you should > remember to include this information in your application. > > I have looked a patch for collectionsmodule.c. In my opinion it is fine realization of binary trees. If there is this class that to me there is no need to create one more copy. My persistence speaks a demand of this type of data. As to my message on the beginning of the project for SoC I ask to consider that this theme has not been lifted :) For me it was a minor question. >> I think, that creation of this type (together with type of pair), will make >> programming more convenient since sorting by function sort will be required >> less often. >> > > How often are you sorting data? I've found that very few of my > operations involve sorting data of any kind, and even if I did have need > of sorting, Python's sorting algorithm is quite fast, likely faster by > nearly a factor of 2 (in the number of comparisons) than the on-line > constructio
Re: [Python-Dev] New-style icons, .desktop file
Martin v. Löwis wrote: > 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? I would say yes. Vista isn't out there yet, and the icons can always be updated in 2.6. Georg ___ 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
On 4/27/06, Georg Brandl <[EMAIL PROTECTED]> wrote: Martin v. Löwis wrote:> 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?I would say yes. Vista isn't out there yet, and the icons can always beupdated in 2.6.OTOH, the ETA for Vista is "just after" 2.5 release (end of 2006 for OEM:s, beginning of 2007 for customers), long before 2.6That said, I don't have any strong preferences either way. (..but I do have a x64 Vista machine running ATM)..just my €0.02 ___ 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] Dropping __init__.py requirement for subpackages
Guido van Rossum wrote: > So I have a very simple proposal: keep the __init__.py requirement for > top-level pacakages, but drop it for subpackages. This should be a > small change. I'm hesitant to propose *anything* new for Python 2.5, > so I'm proposing it for 2.6; if Neal and Anthony think this would be > okay to add to 2.5, they can do so. I'm going to skip the discussion thread (or is it a flame war? cannot tell from the thread pattern), but here are my votes: +0 on dropping the requirement for subpackages in 2.X (this will break tools, but probably not break much code, and fixing the tools should be straightforward) (+1 on dropping it in 3.X) -1 on dropping the requirement for packages in 2.X (-0 on dropping it in 3.X) +0 on making this change in 2.5 ___ 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] inheriting basic types more efficiently
The real misunderstanding lies somewhere else. I thought that the bitarray's instance would have more control over the long type's instance, like with the mutable types. I thought that the long type's superclass would provide methods similar to __setitem__ that would allow the bitarray instance to even *refresh* (or substitute) the long instance in place. The result would be a freshly created long instance substituting the old one. But the immuntable types do not offer such a feature because one cannot substitute the long instance without breaking the bitarray instance too. On Thu, 27 Apr 2006 07:20:47 +0200 "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Dennis Heuer wrote: > > The reason why I'd like to use the long type as the base of my bitarray > > type is that the long type is already implemented as an array and > > working efficiently with large amounts of bytes. > > This is wrong; you are mixing up the "is-a" and "has-a" relationships. > > While it might be useful to have long as the *representation* of a > bitarray, it's not the case that a bitarray *is* a long. A bitarray > is a sequence type and should implement all aspects of the sequence > protocol; long is a numeric type and should implement numeric > operations. While the operators for these somewhat overlap (for + and > *), the semantics of the operators never overlaps. So long and > bitarray are completely distinct types, not subtypes of each other. > > IOW, you should do > > class bitarray: > def __init__(self): > self.value = 0L > ... > > 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] Dropping __init__.py requirement for subpackages
Guido van Rossum wrote: > So I have a very simple proposal: keep the __init__.py requirement for > top-level pacakages, but drop it for subpackages. This should be a > small change. I'm hesitant to propose *anything* new for Python 2.5, > so I'm proposing it for 2.6; if Neal and Anthony think this would be > okay to add to 2.5, they can do so. I haven't scanned this whole thread yet, but my first thought was to just try to find a way to give a better error message if we find a candidate package directory, but there's no __init__.py file. i.e. something like: ImportError: __init__.py not found in directory '/foo' for package 'foo' I like the fact that __init__.py documents, right there in the file system directory listing, that the current directory is a Python package. 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] what do you like about other trackers and what do you hate about SF?
Brett Cannon wrote: > I am starting to hash out what the Call for Trackers is going to say > on the Infrastructure mailing list. Laura Creighton suggested we have > a list of features that we would like to see and what we all hate > about SF so as to provide some guidelines in terms of how to set up > the test trackers that people try to sell us on. > > So, if you could, please reply to this message with ONE thing you have > found in a tracker other than SF that you have liked (especially > compared to SF) and ONE thing you dislike/hate about SF's tracker. I > will use the replies as a quick-and-dirty features list of stuff that > we would like to see demonstrated in the test trackers. I'd like to have an ability to interconnect bugs (this patch fixes this bug, this bug is related to this other bug, etc.) with automatic closing of dependents etc. In SF, I hate that there is no possibility to close a bug with a checkin. And that SF displays only the full name of an item submitter, but not commenters. Georg ___ 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] Dropping __init__.py requirement for subpackages
Guido> One particular egregious problem is that *subpackage* are subject Guido> to the same rule. It so happens that there is essentially only Guido> one top-level package in the Google code base, and it already has Guido> an __init__.py file. But developers create new subpackages at a Guido> frightening rate, and forgetting to do "touch __init__.py" has Guido> caused many hours of lost work, not to mention injuries due to Guido> heads banging against walls. That's why God created make: install: touch __init__.py blah blah blah 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] RELEASED Python 2.5 (alpha 2)
On behalf of the Python development team and the Python community, I'm happy to announce the second alpha release of Python 2.5. This is an *alpha* release of Python 2.5. As such, it is not suitable for a production environment. It is being released to solicit feedback and hopefully discover bugs, as well as allowing you to determine how changes in 2.5 might impact you. If you find things broken or incorrect, please log a bug on Sourceforge. In particular, note that changes to improve Python's support of 64 bit systems might require authors of C extensions to change their code. More information (as well as source distributions and Windows installers) are available from the 2.5 website: http://www.python.org/2.5/ Since the first alpha, a host of bug fixes and smaller new features have been added. See the release notes (available from the 2.5 webpage) for more. The plan from here is for either one more alpha release, or (more likely) moving to the beta releases, then moving to a 2.5 final release around August. PEP 356 includes the schedule and will be updated as the schedule evolves. The new features in Python 2.5 are described in Andrew Kuchling's What's New In Python 2.5. It's available from the 2.5 web page. Amongst the language features added include conditional expressions, the with statement, the merge of try/except and try/finally into try/except/finally, enhancements to generators to produce a coroutine kind of functionality, and a brand new AST-based compiler implementation. New modules added include hashlib, ElementTree, sqlite3 and ctypes. In addition, a new profiling module cProfile was added. In addition, in the second alpha we have the new 'mailbox' module (a product of last years Google Summer of Code). Enjoy this new release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgpFtTGHocMYr.pgp Description: PGP signature ___ 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] Dropping __init__.py requirement for subpackages
>> Not that it would count in any way, but I'd prefer to keep it. How >> would I mark a subdirectory as "not-a-package" otherwise? Guido> What's the use case for that? Have you run into this requirement? Yes, we run into it. We typically install a package with any resources in a resources subdirectory. Now, those resources subdirectories generally don't contain Python files (Glade files are the most frequent occupants), but there's no reason they couldn't contain Python files. 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] trunk is UNFROZEN
The release is done. The trunk is now unfrozen. Thanks, 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] Dropping __init__.py requirement for subpackages
On 4/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:[...] So I have a very simple proposal: keep the __init__.py requirement fortop-level pacakages, but drop it for subpackages. This should be asmall change. I'm hesitant to propose *anything* new for Python 2.5,so I'm proposing it for 2.6; if Neal and Anthony think this would beokay to add to 2.5, they can do so. Damn these threads are so quick they are born and die off in 24 hours and don't give enough time for people to comment :( I'm a bit late in the thread, but I'm +1 (for 2.5) for the following reason. There are mainly two use cases for having a couple of modules foo.bar, and foo.zbr: 1. foo.bar and foo.zbr are both part of the same _package_, and are distributed together; 2. foo.bar and foo.zbr are two independent modules, distributed separately, but which share a common 'foo' _namespace_, to denote affiliation with a project. The use case #1 is arguably more common, but use case #2 is also very relevant. It happens for a lot of GNOME python bindings, for example, where we used to have gnome, gnome.ui, gnome.vfs, gnome.applet, etc. Now the problem. Suppose you have the source package python-foo-bar, which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This would make a module called " foo.bar" available. Likewise, you can have the source package python-foo-zbr, which installs $pythondir/foo/__init__.py and $pythondir/foo/zbr.py. This would make a module called "foo.zbr" available. The two packages above install the file $pythondir/foo/__init__.py. If one of them adds some content to __init__.py, the other one will overwrite it. Packaging these two packages for e.g. debian would be extremely difficult, because no two .deb packages are allowed to intall the same file. One solution is to generate the __init__.py file with post-install hooks and shell scripts. Another solution would be for example to have only python-foo-bar install the __init__.py file, but then python-foo-zbr would have to depend on python-foo-bar, while they're not really related. I hope I made the problem clear enough, and I hope people find this a compelling argument in favour of eliminating the need for __init__.py. Regards,Gustavo Carneiro. ___ 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] A better and more basic array type
Yes, this was previously "inheriting basic types more efficiently" but
now I want something different ;)
I looked at the array type and found it quite C-ish. It is also not
suited for arithmetics because it's a sequence type like a constrained
list and not efficiently (and comfortably) usable like a *sliceable*
integer. I'd rather like to find a basic built-in array type in python,
which doesn't even ask for the format but just deals with the technical
issues internally. This array type works like the long type but is
mutable and supports *slicing* (focusing on a bit-range in the
presentation of the number). The advantage of this array is that it is
fully supporting arithmetics--even on slices--, that there is no need
for boundary-checking, and that this mutable array type is actually
usable as a superclass for new types. The other type of array, the
constrained list, is inclusive:
x = array()
x += 255# x now holds the number 255 or, in other words, the first
# 8 bits are set to 1
x += "1010" # x interprets "1010" as a bit-pattern and adds 10
x.step(8) # telling x that, from now on, a *unit* is 8-bit long
# (for correct slicing and iteration; this is not
# related to the real/internal array layout)
x[:] = 0# clearing all bits or setting x to zero
f = open("binary file", "rb")
x += f.read()
for n in x: # n holds always the next 8 bit (a byte)
y = x[4:6] # stores the fifth and the sixth byte in y
x.step(1) # telling x that, from now on, a *unit* is 1-bit long
z = x[4:6] # stores the fifth and the sixth bit in z
x[0:2] = z # overwrites the first two bits in x with the two bits in z
Possibly the step attribute can become problematic and it's better to
define a fix step at initialization. Smaller bit-packages from otherwise
compatible types could be packed up with trailing zeroes.
I hope that somebody agrees and is already starting to implement this
new array type. My best wishes are with you.
___
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] Type-Def-ing Python
Dear Python Community, I have been trying to research how to type-def python. I want to type-def python so that I can use it as a static analyzer to check for bugs. I have been going over research on this field and I came upon Brett Cannon's thesis in which he tweaks the compiler and shows that type-defing python would not help the compiler achieve a 5% performace increase. Brett Cannon, "Localized Type Inference of Atomic Types in Python": http://www.ocf.berkeley.edu/~bac/thesis.pdf I was wondering if anyone could help me contact him so that I could might ask him for his source code and try to use type-defing as a bug-finder. With thanks, Brian ___ 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] Dropping __init__.py requirement for subpackages
"Gustavo Carneiro" <[EMAIL PROTECTED]> writes: > Now the problem. Suppose you have the source package python-foo-bar, > which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This > would make a module called "foo.bar" available. Likewise, you can have the > source package python-foo-zbr, which installs $pythondir/foo/__init__.py and > $pythondir/foo/zbr.py. This would make a module called "foo.zbr" available. > > The two packages above install the file $pythondir/foo/__init__.py. If > one of them adds some content to __init__.py, the other one will overwrite > it. Packaging these two packages for e.g. debian would be extremely > difficult, because no two .deb packages are allowed to intall the same file. > > One solution is to generate the __init__.py file with post-install hooks > and shell scripts. Another solution would be for example to have only > python-foo-bar install the __init__.py file, but then python-foo-zbr would > have to depend on python-foo-bar, while they're not really related. Yet another solution would be to put foo/__init__.py into a third package, e.g. python-foo, on which both python-foo-bar and python-foo-zbr depend. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.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] Dropping __init__.py requirement for subpackages
On 4/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: Alrighty then. The list has about 12 hours to convince me (and you) that it's a bad idea to generate that warning. I'll be asleep by the time the trunk un-freezes, and I have a string of early meetings tomorrow. I'll get to it somewhere in the afternoon :) I could check it in, except the make-testall I ran overnight showed a small problem: the patch would generate a number of spurious warnings in the trunk:/home/thomas/python/python/trunk/Lib/gzip.py:9: ImportWarning: Not importing directory '/home/thomas/python/python/trunk/Modules/zlib': missing __init__.py /home/thomas/python/python/trunk/Lib/ctypes/__init__.py:8: ImportWarning: Not importing directory '/home/thomas/python/python/trunk/Modules/_ctypes': missing __init__.py(and a few more zlib ones.) The reason for that is that ./Modules is added to the import path, by a non-installed Python. This is because of the pre-distutils Modules/Setup-style build method of modules (which is still sometimes used.) I can't find where Modules is added to sys.path, though, even if I wanted to remove it :)So, do we: a) forget about the warning because of the layout of the svn tree (bad, imho) 2) rename Modules/zlib and Modules/_ctypes to avoid the warning (inconvenient, but I don't know how inconvenient) - fix the build procedure so Modules isn't added to sys.path unless it absolutely has to (which is only very rarely the case, I believe) or lastly, make regrtest.py ignore those specific warnings? -- 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
Re: [Python-Dev] Dropping __init__.py requirement for subpackages
At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote: >"Gustavo Carneiro" <[EMAIL PROTECTED]> writes: > > > Now the problem. Suppose you have the source package python-foo-bar, > > which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This > > would make a module called "foo.bar" available. Likewise, you can have the > > source package python-foo-zbr, which installs > $pythondir/foo/__init__.py and > > $pythondir/foo/zbr.py. This would make a module called "foo.zbr" > available. > > > > The two packages above install the file $pythondir/foo/__init__.py. If > > one of them adds some content to __init__.py, the other one will overwrite > > it. Packaging these two packages for e.g. debian would be extremely > > difficult, because no two .deb packages are allowed to intall the same > file. > > > > One solution is to generate the __init__.py file with post-install hooks > > and shell scripts. Another solution would be for example to have only > > python-foo-bar install the __init__.py file, but then python-foo-zbr would > > have to depend on python-foo-bar, while they're not really related. > >Yet another solution would be to put foo/__init__.py into a third >package, e.g. python-foo, on which both python-foo-bar and >python-foo-zbr depend. Or you can package them with setuptools, and declare foo to be a namespace package. If installing in the mode used for building RPMs and debs, there will be no __init__.py. Instead, each installs a .pth file that ensures a dummy package object is created in sys.modules with an appropriate __path__. This solution is packaging-system agnostic and doesn't require any special support from the packaging tool. (The downside, however, is that neither foo.bar nor foo.zbr's __init__.py will be allowed to have any content, since in some installation scenarios there will be no __init__.py 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] Dropping __init__.py requirement for subpackages
On 4/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:>"Gustavo Carneiro" <[EMAIL PROTECTED]> writes:>> > Now the problem. Suppose you have the source package python-foo-bar, > > which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This> > would make a module called "foo.bar" available. Likewise, you can have the> > source package python-foo-zbr, which installs > $pythondir/foo/__init__.py and> > $pythondir/foo/zbr.py. This would make a module called "foo.zbr"> available.> >> > The two packages above install the file $pythondir/foo/__init__.py. If > > one of them adds some content to __init__.py, the other one will overwrite> > it. Packaging these two packages for e.g. debian would be extremely> > difficult, because no two .deb packages are allowed to intall the same > file.> >> > One solution is to generate the __init__.py file with post-install hooks> > and shell scripts. Another solution would be for example to have only> > python-foo-bar install the __init__.py file, but then python-foo-zbr would > > have to depend on python-foo-bar, while they're not really related.>>Yet another solution would be to put foo/__init__.py into a third>package, e.g. python-foo, on which both python-foo-bar and >python-foo-zbr depend. You can't be serious. One package just to install a __init__.py file? Or you can package them with setuptools, and declare foo to be a namespacepackage. Let's not assume setuptools are always used, shall we? If installing in the mode used for building RPMs and debs, therewill be no __init__.py. Instead, each installs a .pth file that ensures adummy package object is created in sys.modules with an appropriate__path__. This solution is packaging-system agnostic and doesn't require any special support from the packaging tool. I don't understand this solution. How can a .pth file create a 'dummy package'? Remember that the objective is to have "foo.bar" and " foo.zbr" modules, not just "bar" and "zbr". But in any case, it already sounds like a convoluted solution. No way it can beat the obvious/simple solution: to remove the need to have __init__.py in the first place. (The downside, however, is that neither foo.bar nor foo.zbr's __init__.pywill be allowed to have any content, since in some installation scenarios there will be no __init__.py at all.) That's ok in the context of this proposal (not having __init__.py 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] Dropping __init__.py requirement for subpackages
On 4/27/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote: On 4/27/06, Phillip J. Eby < [EMAIL PROTECTED]> wrote: At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:>"Gustavo Carneiro" <[EMAIL PROTECTED] > writes:>> > Now the problem. Suppose you have the source package python-foo-bar, > > which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This> > would make a module called "foo.bar" available. Likewise, you can have the> > source package python-foo-zbr, which installs > $pythondir/foo/__init__.py and> > $pythondir/foo/zbr.py. This would make a module called "foo.zbr"> available.> >> > The two packages above install the file $pythondir/foo/__init__.py. If > > one of them adds some content to __init__.py, the other one will overwrite> > it. Packaging these two packages for e.g. debian would be extremely> > difficult, because no two .deb packages are allowed to intall the same file. > >Yet another solution would be to put foo/__init__.py into a third>package, e.g. python-foo, on which both python-foo-bar and >python-foo-zbr depend. You can't be serious. One package just to install a __init__.py file?Sure. Have you counted the number of 'empty' packages in Debian lately? Besides, Guido's original proposal is not a fix for your problem, either; he only proposes to change the requirement for *sub*packages. -- 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
Re: [Python-Dev] Dropping __init__.py requirement for subpackages
On 4/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: On 4/27/06, Gustavo Carneiro < [EMAIL PROTECTED]> wrote: On 4/27/06, Phillip J. Eby < [EMAIL PROTECTED]> wrote: At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:>"Gustavo Carneiro" <[EMAIL PROTECTED] > writes:>> > Now the problem. Suppose you have the source package python-foo-bar, > > which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This> > would make a module called "foo.bar" available. Likewise, you can have the> > source package python-foo-zbr, which installs > $pythondir/foo/__init__.py and> > $pythondir/foo/zbr.py. This would make a module called "foo.zbr"> available.> >> > The two packages above install the file $pythondir/foo/__init__.py. If > > one of them adds some content to __init__.py, the other one will overwrite> > it. Packaging these two packages for e.g. debian would be extremely> > difficult, because no two .deb packages are allowed to intall the same file. > >Yet another solution would be to put foo/__init__.py into a third>package, e.g. python-foo, on which both python-foo-bar and >python-foo-zbr depend. You can't be serious. One package just to install a __init__.py file? Sure. Have you counted the number of 'empty' packages in Debian lately? Sure. That is already a problem; let's not make it a worse problem for no good reason; I haven't heard a good reason to keep the __init__.py file besides backward compatibility concerns. Besides, Guido's original proposal is not a fix for your problem, either; he only proposes to change the requirement for *sub*packages. It *is* a solution for my problem. I don't need the __init__.py file for anything, since I don't need anything defined in the the 'foo' namespace, only the subpackages foo.bar and foo.zbr . ___ 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] Dropping __init__.py requirement for subpackages
On 4/27/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote: Besides, Guido's original proposal is not a fix for your problem, either; he only proposes to change the requirement for *sub*packages. It *is* a solution for my problem. I don't need the __init__.py file for anything, since I don't need anything defined in the the 'foo' namespace, only the subpackages foo.bar and foo.zbr No. Guido's original proposal is not a fix for your problem, because *it doesn't affect the 'foo' namespace*. Guido's original proposal still requires foo/__init__.py for your namespace to work, it just makes foo/bar/__init__.py and foo/zbr/__init__.py optional. -- 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
Re: [Python-Dev] New-style icons, .desktop file
By the way, check out the new Python/Mac iconography that Jacob Rus has put together (with lots of advice from others :-), at http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png. Tim Parkin's new logo sure started something. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping __init__.py requirement for subpackages
On 4/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: On 4/27/06, Gustavo Carneiro < [EMAIL PROTECTED]> wrote: Besides, Guido's original proposal is not a fix for your problem, either; he only proposes to change the requirement for *sub*packages. It *is* a solution for my problem. I don't need the __init__.py file for anything, since I don't need anything defined in the the 'foo' namespace, only the subpackages foo.bar and foo.zbr No. Guido's original proposal is not a fix for your problem, because *it doesn't affect the 'foo' namespace*. Guido's original proposal still requires foo/__init__.py for your namespace to work, it just makes foo/bar/__init__.py and foo/zbr/__init__.py optional. Damn, you're right, I confused subpackage with submodule :P In that case, can I counter-propose to stop requiring the __init__.py file in [foo/__init__.py, foo/bar.py] ? ;-) The proposal would mean that a directory 'foo' with a single file bar.py would make the module 'foo.bar' available if the parent directory of 'foo' is in sys.path./me faces the pitchforks. ___ 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] Internal documentation for egg formats now available
Phillip J. Eby wrote: > Please see > http://svn.python.org/projects/sandbox/trunk/setuptools/doc/formats.txt for > source, or http://peak.telecommunity.com/DevCenter/EggFormats for an > HTML-formatted version. > > Included are summary descriptions of the formats of all of the standard > metadata produced by setuptools, along with pointers to the existing > manuals that describe the syntax used for representing requirements, entry > points, etc. as text. The .egg, .egg-info, and .egg-link formats and > layouts are also specified, along with the filename syntax used to embed > project/version/Python version/platform metadata. Last, but not least, > there are detailed explanations of how resources (such as C extensions) are > extracted on-the-fly and cached, how C extensions get imported from > zipfiles, and how EasyInstall works around the limitations of Python's > default sys.path initialization. > > If there's anything else you'd like in there, please let me know. Thanks. Just read that you are hijacking site.py for setuptools' "just works" purposes. Please be aware that by allowing .pth files in all PYTHONPATH directories you are opening up a security hole - anyone with write-permission to one of these .pth files could manipulate other user's use of Python. That's the reason why only site-packages .pth files are taken into account, since normally only root has write access to this directory. The added startup time for scanning PYTHONPATH for .pth files and processing them is also not mentioned in the documentation. Every Python invocation would have to pay for this - regardless of whether eggs are used or not. I really wish that we could agree on an installation format for package (meta) data that does *not* rely on ZIP files. All the unnecessary magic that you have in your design would just go away - together with most of the issues people on this list have with it. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 27 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] New-style icons, .desktop file
On Thursday 27 April 2006 11:57, Bill Janssen wrote: > By the way, check out the new Python/Mac iconography that Jacob Rus > has put together (with lots of advice from others :-), at > http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png. Very nice! I just might have to start using some of these modern desktops just to get all the pretty pictures. -Fred -- Fred L. Drake, Jr. ___ 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] Dropping __init__.py requirement for subpackages
On 4/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > I could check it in, except the make-testall I ran overnight showed a small > problem: the patch would generate a number of spurious warnings in the > trunk: > > /home/thomas/python/python/trunk/Lib/gzip.py:9: > ImportWarning: Not importing directory > '/home/thomas/python/python/trunk/Modules/zlib': missing > __init__.py > > /home/thomas/python/python/trunk/Lib/ctypes/__init__.py:8: > ImportWarning: Not importing directory > '/home/thomas/python/python/trunk/Modules/_ctypes': missing > __init__.py > > (and a few more zlib ones.) The reason for that is that ./Modules is added > to the import path, by a non-installed Python. This is because of the > pre-distutils Modules/Setup-style build method of modules (which is still > sometimes used.) I can't find where Modules is added to sys.path, though, > even if I wanted to remove it :) > > So, do we: > a) forget about the warning because of the layout of the svn tree (bad, > imho) > 2) rename Modules/zlib and Modules/_ctypes to avoid the warning > (inconvenient, but I don't know how inconvenient) > - fix the build procedure so Modules isn't added to sys.path unless it > absolutely has to (which is only very rarely the case, I believe) > or lastly, make regrtest.py ignore those specific warnings? I'd say the latter. That's how we deal with warnings during the test suite in general don't we? -- --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] Internal documentation for egg formats now available
At 06:47 PM 4/27/2006 +0200, M.-A. Lemburg wrote: >Just read that you are hijacking site.py for setuptools' >"just works" purposes. "hijacking" isn't the word I'd use; "wrapping" is what it actually does. The standard site.py is executed, there is just some pre- and post-processing of sys.path. >Please be aware that by allowing .pth files in all PYTHONPATH >directories you are opening up a security hole - anyone with >write-permission to one of these .pth files could manipulate >other user's use of Python. FUD. Write access to a PYTHONPATH-listed directory already implies complete control over the user's Python environment. This doesn't introduce any issues that aren't implicit in the very existence of PYTHONPATH. >That's the reason why only site-packages .pth files are >taken into account, since normally only root has write >access to this directory. False. On OS X, Python processes any .pth files that are found in the ~/Library/Python2.x/site-packages directory. (Which means, by the way, that OS X users don't need most of these hacks; they just point their install directory to their personal site-packages, and it already Just Works. Setuptools only introduces PYTHONPATH hacks to make this work on *other* platforms.) >The added startup time for scanning PYTHONPATH for .pth >files and processing them is also not mentioned in the >documentation. Every Python invocation would have to pay >for this - regardless of whether eggs are used or not. FUD again. This happens if and only if: 1. You used easy_install to install a package in such a way that the .pth file is required (i.e., you don't choose multi-version mode or single-version externally-managed mode) 2. You include the affected directory in PYTHONPATH So the idea that "every Python invocation would have to pay for this" is false. People who care about the performance have plenty of options for controlling this. Is there a nice HOWTO that explains what to do if you care more about performance than convenience? No. Feel free to contribute one. >I really wish that we could agree on an installation format >for package (meta) data that does *not* rely on ZIP files. There is one already, and it's used if you select single-version externally-managed mode explicitly, or if you install using --root. >All the unnecessary magic that you have in your design would >just go away - together with most of the issues people on this >list have with it. Would you settle for a way to make a one-time ~/.pydistutils.cfg entry that will make setuptools act the way you want it to? That is, a way to make setuptools-based packages default to --single-version-externally-managed mode for installation on a given machine or machine(s)? That way, you'll never have to wonder whether a package uses setuptools or not, you can just "setup.py install" and be happy. ___ 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] Type-Def-ing Python
"Brian C. Lum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Brett Cannon, "Localized Type Inference of Atomic Types in Python": > http://www.ocf.berkeley.edu/~bac/thesis.pdf > > I was wondering if anyone could help me contact him so that I could might > ask him for his source code and try to use type-defing as a bug-finder. He will probably see this, but if he does not, he posts here regularly so just check the archives for the last week. ___ 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] traceback.py still broken in 2.5a2
The change below was rolled back because it broke other stuff. But IMO it is actually necessary to fix this, otherwise those few exceptions that don't derive from Exception won't be printed correctly by the traceback module: guido:~/p/osx guido$ ./python.exe Python 2.5a2 (trunk:45765, Apr 27 2006, 11:36:10) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def f(): ... raise KeyboardInterrupt ... >>> f() Traceback (most recent call last): File "", line 1, in File "", line 2, in f KeyboardInterrupt >>> import traceback >>> try: ... f() ... except: ... traceback.print_exc() ... Traceback (most recent call last): File "", line 2, in File "", line 2, in f >>> --Guido -- Forwarded message -- From: phillip.eby <[EMAIL PROTECTED]> Date: Mar 24, 2006 3:10 PM Subject: [Python-checkins] r43299 - python/trunk/Lib/traceback.py To: [EMAIL PROTECTED] Author: phillip.eby Date: Fri Mar 24 23:10:54 2006 New Revision: 43299 Modified: python/trunk/Lib/traceback.py Log: Revert r42719, because the isinstance() check wasn't redundant; formatting a string exception was causing a TypeError. Modified: python/trunk/Lib/traceback.py == --- python/trunk/Lib/traceback.py (original) +++ python/trunk/Lib/traceback.py Fri Mar 24 23:10:54 2006 @@ -158,7 +158,7 @@ """ list = [] if (type(etype) == types.ClassType -or issubclass(etype, Exception)): +or (isinstance(etype, type) and issubclass(etype, Exception))): stype = etype.__name__ else: stype = etype ___ Python-checkins mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-checkins -- --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] traceback.py still broken in 2.5a2
At 11:38 AM 4/27/2006 -0700, Guido van Rossum wrote: >The change below was rolled back because it broke other stuff. But IMO >it is actually necessary to fix this, Huh? The change you showed wasn't reverted AFAICT; it's still on the trunk. > otherwise those few exceptions >that don't derive from Exception won't be printed correctly by the >traceback module: It looks like the original change (not the change you listed) should've been using "issubclass(etype, BaseException)". (I only reverted the removal of 'isinstance()', which was causing string exceptions to break.) Anyway, looks like a four-letter fix (i.e. add "Base" there), unless there was some other problem I'm missing? ___ 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] traceback.py still broken in 2.5a2
On 4/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 11:38 AM 4/27/2006 -0700, Guido van Rossum wrote: > >The change below was rolled back because it broke other stuff. But IMO > >it is actually necessary to fix this, > > Huh? The change you showed wasn't reverted AFAICT; it's still on the trunk. Sorry. I meant a different change in the same piece of code. > > otherwise those few exceptions > >that don't derive from Exception won't be printed correctly by the > >traceback module: > > It looks like the original change (not the change you listed) should've > been using "issubclass(etype, BaseException)". (I only reverted the > removal of 'isinstance()', which was causing string exceptions to break.) > > Anyway, looks like a four-letter fix (i.e. add "Base" there), unless there > was some other problem I'm missing? Correct, that's the fix I'm looking for. -- --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] New-style icons, .desktop file
Simon Dahlbacka wrote: > OTOH, the ETA for Vista is "just after" 2.5 release (end of 2006 for > OEM:s, beginning of 2007 for customers), long before 2.6 > > That said, I don't have any strong preferences either way. (..but I do > have a x64 Vista machine running ATM) Good to know, but unfortunately, not very helpful in the end: Even if I wanted to include these icons, I still had no clue whatsoever on how to do that. What files do I need to deploy into what locations for this to "work", and how do I determine whether or not to use the "Vista approach" (assuming it is different from the "pre-Vista approach")? 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] inheriting basic types more efficiently
Dennis Heuer wrote: > The real misunderstanding lies somewhere else. I thought that the > bitarray's instance would have more control over the long type's > instance, like with the mutable types. I thought that the long type's > superclass would provide methods similar to __setitem__ that would > allow the bitarray instance to even *refresh* (or substitute) the long > instance in place. The result would be a freshly created long instance > substituting the old one. But the immuntable types do not offer such a > feature because one cannot substitute the long instance without > breaking the bitarray instance too. Maybe that's the misunderstanding: but then you are still left with the mis-design. Even if long was mutable, or even if you used a mutable type as the base type (such as array.array), you *still* shouldn't inherit from it - these types are not in an "is-a" relationship. 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] A better and more basic array type
Dennis Heuer wrote: > I hope that somebody agrees and is already starting to implement this > new array type. My best wishes are with you. This is off-topic for python-dev. Please post to comp.lang.python instead. 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] Internal documentation for egg formats now available
Phillip J. Eby wrote: > At 06:47 PM 4/27/2006 +0200, M.-A. Lemburg wrote: >> Just read that you are hijacking site.py for setuptools' >> "just works" purposes. > > "hijacking" isn't the word I'd use; "wrapping" is what it actually > does. The standard site.py is executed, there is just some pre- and > post-processing of sys.path. Whatever you call it: you're fiddling with the standard Python distribution again, without letting your users know about it. Note that sitecustomize.py is intended for site local changes that admin wants to implement. >> Please be aware that by allowing .pth files in all PYTHONPATH >> directories you are opening up a security hole - anyone with >> write-permission to one of these .pth files could manipulate >> other user's use of Python. > > FUD. Write access to a PYTHONPATH-listed directory already implies > complete control over the user's Python environment. This doesn't > introduce any issues that aren't implicit in the very existence of > PYTHONPATH. Really ? How often do you check the contents of a .pth file ? How often do you check sys.path of a running interpreter to see whether some .pth file has added extra entries that you weren't aware of ? Note that I was talking about the .pth file being writable, not the directory. Even if they are not writable by non-admins, the .pth files can point to directories which are. Combine that with the -m option of the Python interpreter and you have the basis for a nice exploit. >> That's the reason why only site-packages .pth files are >> taken into account, since normally only root has write >> access to this directory. > > False. On OS X, Python processes any .pth files that are found in the > ~/Library/Python2.x/site-packages directory. Hmm, that was new to me. OTOH, it's a very special case and falls under the "normally only root" clause :-) - Mac users are often enough their own admins; I suppose that's why Jack added this: if sys.platform == 'darwin': # for framework builds *only* we add the standard Apple # locations. Currently only per-user, but /Library and # /Network/Library could be added too > (Which means, by the way, > that OS X users don't need most of these hacks; they just point their > install directory to their personal site-packages, and it already Just > Works. Setuptools only introduces PYTHONPATH hacks to make this work on > *other* platforms.) > >> The added startup time for scanning PYTHONPATH for .pth >> files and processing them is also not mentioned in the >> documentation. Every Python invocation would have to pay >> for this - regardless of whether eggs are used or not. > > FUD again. This happens if and only if: > > 1. You used easy_install to install a package in such a way that the > .pth file is required (i.e., you don't choose multi-version mode or > single-version externally-managed mode) > > 2. You include the affected directory in PYTHONPATH > > So the idea that "every Python invocation would have to pay for this" is > false. People who care about the performance have plenty of options for > controlling this. > > Is there a nice HOWTO that explains what to do if you care more about > performance than convenience? No. Feel free to contribute one. Here's a HOWTO to optimize startup time, without loosing convenience: * build Python with all builtin modules statically linked into the interpreter * setup PYTHONPATH to just include the directories you really care about * avoid putting any ZIP archives on PYTHONPATH, except for python24.zip (there are better alternatives; see below) * avoid using .pth files If you run a lot of scripts, you'll also want to do keep this in mind: * start Python with option -s (avoids importing site.py and among other things, parsing .pth files), if you're running a script More startup time can be saved by using an approach like the one described in mxCGIPython which adds the complete Python stdlib to the interpreter binary, effectively turning the Python installation into a single file: http://www.egenix.com/files/python/mxCGIPython.html >> I really wish that we could agree on an installation format >> for package (meta) data that does *not* rely on ZIP files. > > There is one already, and it's used if you select single-version > externally-managed mode explicitly, or if you install using --root. No, I'm talking about a format which has the same if not more benefits as what you're trying to achieve with the .egg file approach, but without all the magic and hacks. It's not like this wouldn't be possible to achieve. >> All the unnecessary magic that you have in your design would >> just go away - together with most of the issues people on this >> list have with it. > > Would you settle for a way to make a one-time ~/.pydistutils.cfg entry > that will make setuptools act the way you want it to? That is, a way to > make setuptools-based packages default to > --singl
Re: [Python-Dev] New-style icons, .desktop file
On 4/27/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Simon Dahlbacka wrote:> OTOH, the ETA for Vista is "just after" 2.5 release (end of 2006 for> OEM:s, beginning of 2007 for customers), long before 2.6>> That said, I don't have any strong preferences either way. (..but I do > have a x64 Vista machine running ATM)Good to know, but unfortunately, not very helpful in the end: Even ifI wanted to include these icons, I still had no clue whatsoever on howto do that. What files do I need to deploy into what locations for this to "work", and how do I determine whether or not to use the "Vistaapproach" (assuming it is different from the "pre-Vista approach")?[Disclaimer: the following is what google told me] it seems that the big icons 256x256 are in fact (or at least can be) PNG format within the .ico file.However, the support for these kinds of icons seems to be somewhat lacking, in particular, the current(including VS2005) resource compilers barf when given such an icon. Given that, it does not really seem feasible to include them..Speaking of icons, do the bundled ico files have to be named py.ico and pyc.ico? (These names does not play along with tab-completion, making the user, me that is, tab twice "unnecessarily" to get to python.exe)/SimonA little bit about me:I've almost completed my Computer Engineering(Embedded systems) degree, just need to get my Master's written down. Professionally I've been developing with python for a few years, but currently I mostly work in C# land.. Lurking around on py-dev for a year or so.. ___ 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
Simon Dahlbacka wrote: > Given that, it does not really seem feasible to include them.. Ok, thanks for the investigation. > Speaking of icons, do the bundled ico files have to be named py.ico and > pyc.ico? No. I think I'll try to drop them altogether, getting the icons from python_icon.exe only. 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
[Python-Dev] "mick-windows" buildbot uptime
We've pretty much gotten settled into our new diggs at work here (ActiveState) so my Windows buildbot machine should have better uptime from now on. Cheers, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Internal documentation for egg formats now available
At 09:54 PM 4/27/2006 +0200, M.-A. Lemburg wrote: >Note that I was talking about the .pth file being >writable, not the directory. Please stop this vague, handwaving FUD. You have yet to explain how this situation is supposed to arise. Is there some platform on which files with a .pth extension are automatically writable by users *when .py files are not also*? If not, then you are talking out of your... um, hat. If files are writable by other users by default, then .py files are too. Once again: *no new vector*. >Even if they are not >writable by non-admins, the .pth files can point >to directories which are. Uh huh. And how does that happen, exactly? Um, the user puts them there? What is your point, exactly? That people can do things insecurely if they're allowed near a computer? >Here's a HOWTO to optimize startup time, without loosing >convenience: I meant, a HOWTO for setuptools users who care about this, although at the moment I have heard only from one -- and you're not, AFAIK, actually a setuptools user. >No, I'm talking about a format which has the same if not >more benefits as what you're trying to achieve with the >.egg file approach, but without all the magic and hacks. > >It's not like this wouldn't be possible to achieve. That may or may not be true. Perhaps if you had participated in the original call to the distutils-sig for developing such a format (back in December 2004), perhaps the design would've been more to your liking. Oh wait... you did: http://mail.python.org/pipermail/distutils-sig/2004-December/004351.html And if you replace 'syspathtools.use()' in that email, with 'pkg_resources.require()', then it describes *exactly how setuptools works with .egg directories today*. Apparently, you hadn't yet thought of any the objections that you are now raising to *the very scheme that you yourself proposed*, until somebody else took the trouble to actually implement it. And now you want to say that I never listen to or implement your proposals? Please. Your email is the first documentation on record of how this system works! >Not really. Then I won't bother adding it, since nobody else asked for it. But don't ever say that I didn't offer you a real solution to the behavior you complained about. Meanwhile, I will take your choice as prima facie evidence that the things you are griping about have no real impact on you, and you are simply trying to make other people conform to your views of how things "should" be, rather than being interested in solving actual problems. It also makes it clear that your opinion about setuptools default installation behavior isn't relevant to any future Python-Dev discussion about setuptools' inclusion in the standard library, because it's: 1. Obviously not a real problem for you (else you'd accept the offer of a feature that would permanently solve it for you) 2. Not something that anybody else has complained about since I made --root automatically activate distutils compatibility In short, the credibility of your whining about this point and my supposed failure to accomodate you is now thoroughly debunked. I added an option to enable this behavior, I made other options enable the behavior where it could be reasonably assumed valid, and I offered you an option you could use to globally disable it for *any* package using setuptools, so that it would never affect you again. (And all of this... to disable the behavior that implements a scheme that you yourself proposed as the best way to do this sort of thing!) ___ 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] what do you like about other trackers and what do you hate about SF?
On Tue, Apr 25, 2006, Brett Cannon wrote: > > So, if you could, please reply to this message with ONE thing you have > found in a tracker other than SF that you have liked (especially > compared to SF) and ONE thing you dislike/hate about SF's tracker. I > will use the replies as a quick-and-dirty features list of stuff that > we would like to see demonstrated in the test trackers. My biggest peeve about SF is the cluttered interface. The basic tracker interface should take two or three screens in 25x80 mode with Lynx. Oh, yes, the tracker must work with Lynx. SF technically qualifies as of the last time I checked, but for several years I was unable to use Lynx to submit bugs. -- 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-checkins] r45721 - python/trunk/Lib/test/test_with.py
>> Author: tim.peters >> Date: Wed Apr 26 03:15:53 2006 >> New Revision: 45721 >> >> Modified: >>python/trunk/Lib/test/test_with.py >> Log: >> Rev 45706 renamed stuff in contextlib.py, but didn't rename >> uses of it in test_with.py. As a result, test_with has been skipped >> (due to failing imports) on all buildbot boxes since. Alas, that's >> not a test failure -- you have to pay attention to the >> >> 1 skip unexpected on PLATFORM: >> test_with >> >> kinds of output at the ends of test runs to notice that this got >> broken. [Nick Coghlan] > That would be my fault - I've got about four unexpected skips I actually > expect because I don't have the relevant external modules built. I must have > missed this new one joining the list. Oh, I don't know. It's always been dubious that regrtest.py treats ImportError exactly the same as test_support.TestSkipped. Hmm. Think I'll do something about that ;-) > ... ___ 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] Must objects with __enter__/__exit__ also supply __context__?
Nick Coghlan wrote: > OTOH, if the two protocols are made orthogonal, then it's clear that the > manager is always the original object with the __context__ method. Then the > three cases are: > > - a pure context manager (only provides __context__) > - a pure managed context (only provides __enter__/__exit__) > - a managed context which can be its own context manager (provides all > three) +1 on keeping the two protocols orthogonal and using this terminology (context manager/managed context). -Edward ___ 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] Must objects with __enter__/__exit__ also supply __context__?
+1 from me too. On 4/27/06, Edward Loper <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: > > OTOH, if the two protocols are made orthogonal, then it's clear that the > > manager is always the original object with the __context__ method. Then the > > three cases are: > > > > - a pure context manager (only provides __context__) > > - a pure managed context (only provides __enter__/__exit__) > > - a managed context which can be its own context manager (provides all > > three) > > +1 on keeping the two protocols orthogonal and using this terminology > (context manager/managed context). > > -Edward > ___ > 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] Type-Def-ing Python
On 4/27/06, Brian C. Lum <[EMAIL PROTECTED]> wrote: > Dear Python Community, > > I have been trying to research how to type-def python. I want to type-def > python so that I can use it as a static analyzer to check for bugs. I > have been going over research on this field and I came upon > Brett Cannon's thesis in which he tweaks the compiler and shows that > type-defing python would not help the compiler achieve a 5% performace > increase. > > Brett Cannon, "Localized Type Inference of Atomic Types in Python": > http://www.ocf.berkeley.edu/~bac/thesis.pdf > > I was wondering if anyone could help me contact him so that I could might > ask him for his source code and try to use type-defing as a bug-finder. > Just so people know, I obviously got the email and will take this off-list. -Brett ___ 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-checkins] Python Regression Test Failures refleak (1)
On 4/22/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [19 Apr 2006, Neal Norwitz] > > test_cmd_line leaked [0, 17, -17] references > > test_filecmp leaked [0, 13, 0] references > > test_threading_local leaked [-93, 0, 0] references > > test_urllib2 leaked [-121, 88, 99] references > > Thanks to Thomas digging into test_threading_local, I checked in what > appeared to be a total leak fix for it last week. On my Windows box, > it's steady as a rock now: > > """ > $ python_d -E -tt ../lib/test/regrtest.py -R:50: test_threading_local > test_threading_local > beginning 55 repetitions > 1234567890123456789012345678901234567890123456789012345 > ... > 1 test OK. > [27145 refs] > """ > > Is it still flaky on other platforms? > > If not, maybe the reported > > test_threading_local leaked [-93, 0, 0] references > > is due to stuff from a _previous_ test getting cleaned up (later than > expected/hoped)? When you first sent this message I was able to reproduce the leaks inconsistently on the box that runs this test. I *think* all that was required was test_cmd_line test_suprocess and test_threading_local (in that order). I suspect that the problem is some process is slow to die. I don't think I can provoke any of these in isolation. I definitely can't provoke them consistently. Today, I wasn't able to provoke them at all. I have disabled the leak warning for: LEAKY_TESTS="test_(cmd_line|ctypes|filecmp|socket|threadedtempfile|threading|urllib2) This is an attempt to reduce the spam. Would people rather me reduce this list so we can try to find the problems? The test runs 2 times per day. Sometimes it gets stuck. But the most you should ever receive is 2 mails a day. 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] [Python-checkins] Python Regression Test Failures refleak (1)
[Neal Norwitz] > ... > I have disabled the leak warning for: > > LEAKY_TESTS="test_(cmd_line|ctypes|filecmp|socket|threadedtempfile|threading|urllib2) > > This is an attempt to reduce the spam. Would people rather me reduce > this list so we can try to find the problems? The test runs 2 times > per day. Sometimes it gets stuck. But the most you should ever > receive is 2 mails a day. I see so much email that 100/day more or less from any particular source wouldn't be noticed. It's possible that increasing the repetition count for _some_ of these tests would make them easier to understand. For example, test_cmd_line settles into a very regular pattern on my box when run more often: C:\Code\python\PCbuild>python_d -E -tt ../lib/test/regrtest.py -R:20: test_cmd_line test_cmd_line beginning 25 repetitions 1234567890123456789012345 . test_cmd_line leaked [36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36] references 1 test OK. IOW, after 5 "warmup " runs, each of the 20 following runs leaked 36 refs. That may be unique to Windows (especially since all the leaks here are due to the tests that call CmdLineTest.exit_code()). ___ 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] 2.5 open issues
If you are addressed on this message, it means you have open issues that need to be resolved for 2.5. Some of these issues are documentation, others are code issues. This information comes from PEP 356. The best way to get me to stop bugging you is to close out these tasks. :-) Who is the owner for getting new icons installed with the new logo? Code issues: +++ Fred, Fredrik, Martin: xmlplus/xmlcore situation re: ElementTree Jeremy: AST compiler issues We should really try to get these resolved soon, especially the XML issue since that could result in some sort of API change. The AST issues should just be bug fixes AFAIK. Documentation missing: +++ Fredrik: ElementTree Gerhard: pysqlite Martin: msilib Thomas: ctypes Thomas, I know you checked in some ctypes docs. Is that everything or is there more coming? It seemed pretty short given the size of ctypes. If you don't expect to have time to finish these tasks, then it's your job to find someone else who will. 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
