Re: [Python-Dev] splitting out bdist_*
Eric Smith writes: And I personally use bdist_rpm for my work, which I distribute to a farm of servers under my control. So no doubt it's used. Sure, but use for internal distribution is very different from to problem its being asked to solve now, isn't it? IIUC, you're basically using RPM as an installer for a standalone application, where you set policy at both ends, packaging and installation. This may be a group of modules which may have internal interdependencies, but very likely the environment doesn't change much. Pretty much anything will do in that kind of situation, and I don't think it would matter to you if there are zero, one, or twelve such tools in stdlib, as long as there's one you like in PyPI somewhere. [That .deb tools are necessarily maintained outside of bdist] proves that [external maintenance] doesn't help given the current state of affairs. I suspect that if all of this additional information needed to build a .deb (for example) could be included as metadata in the python package (using the word package loosely), that it would be. It would make the ultimate packager's life easier, and it's no real burden for the original author. I'm not sure what you mean by it would be. Are you referring to what I believe to be true, that because Python and Python-based apps need to integrate with the rest of the OS, it's quite burdensome for module authors to include the necessary information, which is likely to vary from packaging tool to packaging tool, and according to policy even among packagers using the same tool? Or do you mean that it would be useful, so it would be nice if such information were included, and that as you see it the required effort would be small? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Guido van Rossum wrote: The new exception could either be a designated (built-in) subclass of StopIteration, or not; I think it would have to not be; otherwise any existing code that catches StopIteration would catch the new exception as well without complaint. Using a different exception raises another question. Would you check whether the return value is None and raise an ordinary StopIteration in that case? Or would return with a value always raise the new exception? If the latter, then 'return' and 'return None' would no longer be equivalent in all cases, which would be rather strange. I think in either case a check in PyIter_Next() would cover most cases If that's acceptable, then the check might as well be for None as the StopIteration value, and there's no need for a new exception. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitting out bdist_*
2009/3/28 Stephen J. Turnbull step...@xemacs.org: Sure, but use for internal distribution is very different from to problem its being asked to solve now, isn't it? IIUC, you're basically using RPM as an installer for a standalone application, where you set policy at both ends, packaging and installation. This may be a group of modules which may have internal interdependencies, but very likely the environment doesn't change much. Pretty much anything will do in that kind of situation, and I don't think it would matter to you if there are zero, one, or twelve such tools in stdlib, as long as there's one you like in PyPI somewhere. I myself would never use such a tool, unless sanctioned by my OS vendor, because I would not trust it not to break my system. But I think bdist_rpm and bdist_deb solve a real deficiency: no uninstallation feature. Thinking of it, that's exactly why I like bdist_wininst so much when I am on windows (and because the consequences of a bad installer from bdist_wininst seem minimal on windows, seems everything is one directory). David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Michele Simionato wrote: On Fri, Mar 27, 2009 at 1:33 PM, Jesse Noller jnol...@gmail.com wrote: Antoine Pitrou: As a matter of fact, the people whom this PEP is supposed to benefit haven't expressed a lot of enthusiasm right now. That's why it looks so academic. That's because most of us who might like this have been patently avoiding this thread. I have been avoiding this thread too - even if I have implemented my own trampoline as everybody else here - because I had nothing to say that was not said already here. But just to add a data point, let me say that I agree with Eby. I am 0+ on the syntax, but please keep the hidden logic simple and absolutely do NOT add confusion between yield and return. Use yield Return(value) or raise SomeException(value), as you like. I still think raise is out due to the fact that it would trigger subsequent except clauses. Guido has (sensibly) ruled out raising StopIteration and complaining if it has value in old code, since there is too much code which cases StopIteration *without* performing such a check. If those two points are accepted as valid, then that leaves the two options as being: 1. Add a new GeneratorReturn exception that will escape from existing code that only traps StopIteration. The only real downside of this is that either return and return None will mean different things in generators (unlike functions) or else return None will need to be special cased to raise StopIteration in the calling code rather than raising GeneratorReturn(None). The latter approach is probably preferable if this option is chosen - any code for dealing with generators as coroutines is going to have to deal with the possibility of bare returns and falling off the end of the function anyway, so the special case really wouldn't be that special. 2. In addition to the yield from syntax for delegating to a subgenerator, also add new syntax for returning values from subgenerators so that the basic return X can continue to trigger SyntaxError. Since option 2 would most likely lead to a bikeshed discussion of epic proportions, I'm currently a fan of option 1 ;) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
On Sat, Mar 28, 2009 at 1:36 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Guido van Rossum wrote: The new exception could either be a designated (built-in) subclass of StopIteration, or not; I think it would have to not be; otherwise any existing code that catches StopIteration would catch the new exception as well without complaint. OK. Using a different exception raises another question. Would you check whether the return value is None and raise an ordinary StopIteration in that case? Or would return with a value always raise the new exception? I'm not sure it matters much, but let's sat the latter. If the latter, then 'return' and 'return None' would no longer be equivalent in all cases, which would be rather strange. They already aren't in generators, 'return' is allowed but 'return None' isn't. I think in either case a check in PyIter_Next() would cover most cases If that's acceptable, then the check might as well be for None as the StopIteration value, and there's no need for a new exception. I don't understand this. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
On Sat, Mar 28, 2009 at 4:34 AM, Nick Coghlan ncogh...@gmail.com wrote: I still think raise is out due to the fact that it would trigger subsequent except clauses. Guido has (sensibly) ruled out raising StopIteration and complaining if it has value in old code, since there is too much code which cases StopIteration *without* performing such a check. If those two points are accepted as valid, then that leaves the two options as being: 1. Add a new GeneratorReturn exception that will escape from existing code that only traps StopIteration. The only real downside of this is that either return and return None will mean different things in generators (unlike functions) or else return None will need to be special cased to raise StopIteration in the calling code rather than raising GeneratorReturn(None). The latter approach is probably preferable if this option is chosen - any code for dealing with generators as coroutines is going to have to deal with the possibility of bare returns and falling off the end of the function anyway, so the special case really wouldn't be that special. It seems so indeed. 2. In addition to the yield from syntax for delegating to a subgenerator, also add new syntax for returning values from subgenerators so that the basic return X can continue to trigger SyntaxError. Since option 2 would most likely lead to a bikeshed discussion of epic proportions, I'm currently a fan of option 1 ;) Me too. It also seems option 2 doesn't help us decide what it should do: I still think that raising StopIteration(value) would be misleading to vanilla users of the generators. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitting out bdist_*
Stephen J. Turnbull wrote: Eric Smith writes: And I personally use bdist_rpm for my work, which I distribute to a farm of servers under my control. So no doubt it's used. Sure, but use for internal distribution is very different from to problem its being asked to solve now, isn't it? IIUC, you're basically using RPM as an installer for a standalone application, where you set policy at both ends, packaging and installation. This may be a group of modules which may have internal interdependencies, but very likely the environment doesn't change much. Pretty much anything will do in that kind of situation, and I don't think it would matter to you if there are zero, one, or twelve such tools in stdlib, as long as there's one you like in PyPI somewhere. I was just pointing out that bdist_rpm has users, and it's not likely to be abandoned. It's certainly true that different users have different use cases for it. It's this lack of understanding of all the use cases that most concerns me about this overall effort. How can we know if we succeeded if we don't all agree on the state we're trying to get to? To be concrete, I think distutils should support (among other things): - entry points for plugins - entry points as used for producing console and windowed scripts - dependency declarations for other python packages - dependency declarations for non-python packages But maybe these goals aren't shared by others, and don't fall into anyone else's make distutils better concept. PJE pointed out A library that targets Python 2.4 and 2.5 and uses wsgiref, sqlite, ctypes, or ElementTree, for example, may have different dependencies depending on the version it is being installed in. Is that something we want to support? [That .deb tools are necessarily maintained outside of bdist] proves that [external maintenance] doesn't help given the current state of affairs. I suspect that if all of this additional information needed to build a .deb (for example) could be included as metadata in the python package (using the word package loosely), that it would be. It would make the ultimate packager's life easier, and it's no real burden for the original author. I'm not sure what you mean by it would be. Are you referring to what I believe to be true, that because Python and Python-based apps need to integrate with the rest of the OS, it's quite burdensome for module authors to include the necessary information, which is likely to vary from packaging tool to packaging tool, and according to policy even among packagers using the same tool? Or do you mean that it would be useful, so it would be nice if such information were included, and that as you see it the required effort would be small? I don't see how they differ. It's definitely true that packagers using the same tool might want to produce different package layouts and no doubt other differences. I don't see why it wouldn't be easy to have these differences driven by different policies acting on the same metadata, or small amounts of custom (per-packager) metadata. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
At 06:52 AM 3/28/2009 -0500, Guido van Rossum wrote: 2. In addition to the yield from syntax for delegating to a subgenerator, also add new syntax for returning values from subgenerators so that the basic return X can continue to trigger SyntaxError. Since option 2 would most likely lead to a bikeshed discussion of epic proportions, I'm currently a fan of option 1 ;) Me too. It also seems option 2 doesn't help us decide what it should do: I still think that raising StopIteration(value) would be misleading to vanilla users of the generators. Agreed. (I still think new syntax is a plus, though, as it helps to clearly signal both the intent to make the generator a subtask and the need to call it with yield-from. Readability counts.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My summit notes (packaging)
On Fri, Mar 27, 2009 at 9:54 PM, Kevin Teague ke...@bud.ca wrote: Tarek, was there any further discussion on Requires vs install_requires or any decisions made on what to do about this? (I've got a +1 ready for including 'install_requires' in the standard package metadata and marking 'Requires' as deprecated if that was put forth :P) Yes that is what we were thinking of doing. (deprectating Requires and Provides and and install_requires) We are working on it. We'll try to organize our work in the wiki in the comng days, so people can participate. Regards Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitting out bdist_*
Eric Smith writes: I was just pointing out that bdist_rpm has users, and it's not likely to be abandoned. OK, I see. I don't think there's a reason to remove useful functionality from the stdlib, unless it's clearly superseded by a similar module. I don't see how they differ. It's definitely true that packagers using the same tool might want to produce different package layouts and no doubt other differences. I don't see why it wouldn't be easy to have these differences driven by different policies acting on the same metadata, or small amounts of custom (per-packager) metadata. My experience in XEmacs has been that Debian, Fedora Core, Gentoo, SuSE, and Mandriva have rather different expressions of things like dependencies, and they tend to have different ideas of how forceful they should be with any given supporting package (when the package system supports different strengths of dependency). Debian, for example, supports predepends (you can't even install the dependent unless the prerequisite is already installed), depends (installing the dependent will also install the prerequisite unless the admin is quite forceful about saying no), recommends (it's easy to say no), and suggests (you only get a message saying Things go better with Coke and a suggestion that you may want to install Coke because you installed Things). In other systems there's either a dependency, or there isn't. Gentoo has use flags which are about as flexible as Debian dependencies, but their taste in recommendations is quite different. I really don't see how that kind of thing can be easily supported by a Python module maintainer, unless they're also the downstream packager. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unladen-Swallow: A faster python
Mark Hammond wrote: On 28/03/2009 9:50 PM, andrew cooke wrote: Tim Roberts wrote: [...] IronPython has certainly shown that Python can be successfully implemented in a JIT compiled VM in a performant way, but it has issues running C extension modules. I'll be curious to see where this project goes. given the comments on python-dev i wonder if this is the first indication that python is going to split into separate implementations for windows and unix (via .net and llvm, respectively)? What comments are they? There is no indication that unladen-swallow is fundamentally broken for Windows, just temporarily broken due to the lack of windows developers/contributors... the comments you are referring to - that windows is not a priority, that they currently have no testing on windows machines, etc. i quote, for example: None of the three of us have Windows machines, nor do we particularly want to acquire them :), and Windows support isn't going to be a big priority. Saying-no-to-fud ly, which part of i wonder don't you understand? i'm not saying it is true, i'm just discussing the possibility. i am getting a little tired of people here acting so defensively... i'm discussing a programming language, not the size of your dick. andrew ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitting out bdist_*
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 28, 2009, at 10:10 AM, Stephen J. Turnbull wrote: I really don't see how that kind of thing can be easily supported by a Python module maintainer, unless they're also the downstream packager. They simply can't. As a package developer, I'd be sort of okay with integrating patches that help downstreams, but I wouldn't be happy about it. I can't test it, and there might be conflicts between the demands of various downstreams. Much more appealing is for me to describe what's in my package with rich enough metadata that downstreams don't need anything else to overlay their build rules according to their own needs. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSc5Lf3EjvBPtnXfVAQJoJQQAjJ4BeTk/ovhPvfJLMOSM+mcB7wz4XaX8 X9YlCnmQzPyNtbPdaaaLtkE86Sk6AC3fGO5hVjrSTANmzI02ztvNw4Lm1+HurTC5 6lghbQ1yEudZ3EgVdFu91jYBHrNPkgQtQA/oaB2/paER/8LeGqBppZiitm9plfHB 0LLHkLtylJ8= =qT/n -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitting out bdist_*
2009/3/29 Stephen J. Turnbull step...@xemacs.org: I really don't see how that kind of thing can be easily supported by a Python module maintainer, unless they're also the downstream packager. Almost none. But in my understanding, that's not what most linux packagers vendors ask about - they will handle the dependencies themselves anyway, because naming conventions and the like are different. What is a pain right now with distutils for packagers is: - how to control which files are installed where - how to control the build (compilation flags, etc...). Packagers generally like autotools packages because they can be customized along each distribution convention. Autotools do not really handle dependencies either, but they can be customized for vastly different kind of deployement (one dir for everything ala gobolinux, along the FHS for most major distributions, etc...) - and the upstream developer doesn't need to care much about it. cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My summit notes (packaging)
On Mar 27, 2009, at 9:25 PM, P.J. Eby wrote: At 03:06 PM 3/27/2009 -0500, Tarek Ziadé wrote: They both aim at the same goal besides a few differences, and they both rely on a new metadata introduced by setuptools, wich is. install_requires. This new metadata extends the metadata. described in PEP 314 but is slightly different from. what is descibred in the Draft PEP 345 (Requires). .. PEP 345 introduces Requires and Provides wich are are implemented in Distutils and PyP, but are not widely used. 40 out of +4000 if I remember correctly. Martin will correct me here if I am wrong. FYI, The reason setuptools uses a different way of specifying requirements is that the PEP-proposed way could not be used without some kind of indexed repository of packages -- and PyPI did not index provides at the time. Also, the PEP-proposed versioning scheme was not compatible with the versioning schemes actually used in the field at the time. There's a deeper issue IMO. As Kevin pointed out, distutil's Requires data works at the module and package level, rather than at the project level. I can see some value in this, but I think working at the project level is a lot simpler and more practically useful. Jim -- Jim Fulton Zope Corporation ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitting out bdist_*
On Mar 28, 2009, at 9:33 AM, Eric Smith wrote: To be concrete, I think distutils should support (among other things): - entry points for plugins - entry points as used for producing console and windowed scripts This strikes me as a nice-to-have, but: 1. I don't think they're two distinct features. 2. I'm not convinced these should go in distutils. I'd rather see an API to get resources from a package, and conventions can be developed among tool developers on how to store that information in a named resource. - dependency declarations for other python packages This is the most important requirement here, I think. As part of this, I'd want to be able to say things like PIL, with JPEG and PNG support compiled in. - dependency declarations for non-python packages This would be very nice to have, but I suspect this is actually much more difficult than Python package dependencies, especially with any pretense at cross-platform expressions of dependencies. PJE pointed out A library that targets Python 2.4 and 2.5 and uses wsgiref, sqlite, ctypes, or ElementTree, for example, may have different dependencies depending on the version it is being installed in. Is that something we want to support? Even simple cases present issues with regard to this. For example, I work on a project that relies on the uuid module, so we declare a dependency on Ka-Ping Ye's uuid module (since we're using Python 2.4). How should we write that in a version-agnostic way if we want to use the standard library version of that module with newer Pythons? -Fred -- Fred Drake fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] mentoring Roundup work
Hello, I have just applied to be considered as GSoC mentor with the PSF, notably work on Roundup. (My ID is 'stefan') I'm a long-term Roundup user and contributor. My recent contributions include the XMLRPC interface, as well as many bug fixes and enhancements. I also spearheaded the migration of python.org from the sf.net bug tracker(s) to bugs.python.org. Please let me know if there are any mailing lists or other channels I should connect to to follow-up. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Guido van Rossum wrote: I think in either case a check in PyIter_Next() would cover most cases If that's acceptable, then the check might as well be for None as the StopIteration value, and there's no need for a new exception. I don't understand this. Maybe I misunderstood what you were saying. What check were you suggesting to perform in PyIter_Next? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unladen-Swallow: A faster python
Mark Hammond wrote: [...I wrote] i'm discussing a programming language, not the size of your dick. Wow, talk about jumping to conclusions :) Is there something you feel the need to get off your chest? i'm not sure how this has ended up in python-dev; i was responding in python and if you read that group my comments may have made a little more sense (there were some hysterics in a separate thread accusing me of saying python was dying because i was concerned about how the discussion groups had evolved). anyway, that had nothing to do with you and i am sorry i responded like that. andrew ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
On Sat, Mar 28, 2009 at 4:37 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Guido van Rossum wrote: I think in either case a check in PyIter_Next() would cover most cases If that's acceptable, then the check might as well be for None as the StopIteration value, and there's no need for a new exception. I don't understand this. Maybe I misunderstood what you were saying. What check were you suggesting to perform in PyIter_Next? I now realize what you were saying. You said effectively the check added to PyIter_Next() might as well check whether the value attribute of the StopIteration is not None, but due to PyCon tiredness last night my brain's English parser didn't come up with any meaningful parse of what you wrote. But it's been answered already -- we can't change the meaning of StopIteration() with a value unequal to None, so it has to be a separate exception, and it should not derive from StopIteration. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unladen-Swallow: A faster python
On Sat, Mar 28, 2009, andrew cooke wrote: Mark Hammond wrote: [...I wrote] i'm discussing a programming language, not the size of your dick. Wow, talk about jumping to conclusions :) Is there something you feel the need to get off your chest? i'm not sure how this has ended up in python-dev; i was responding in python and if you read that group my comments may have made a little more sense (there were some hysterics in a separate thread accusing me of saying python was dying because i was concerned about how the discussion groups had evolved). There certainly was no such accusation. You said that c.l.py was in decline (your own word), and I made reference to the ancient Usenet is dead, news at 11 meme. http://groups.google.com/group/comp.lang.python/msg/0b3fbfcdb92ae0e3 Mark's question seems pertinent. ;-) -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ At Resolver we've found it useful to short-circuit any doubt and just refer to comments in code as 'lies'. :-) --Michael Foord paraphrases Christian Muirhead on python-dev, 2009-3-22 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Guido van Rossum wrote: But it's been answered already -- we can't change the meaning of StopIteration() with a value unequal to None, so it has to be a separate exception, and it should not derive from StopIteration. How about having StopIteration be a subclass of the new exception? Then things that want to get generator return values only have one exception to catch, and things that only know about StopIteration will fail to catch the new exception. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
2009/3/25 Antoine Pitrou solip...@pitrou.net: I'm not a Windows user, but I suppose it boils down to whether people are comfortable with the command-line or not (which even many Windows /developers/ aren't). Since having GUIs for everything is part of the Windows philosophy, it's a fair expectation that Python libraries come with graphical Windows installers. The people who use pythonlibraries are programmers. It can be expected that they are comfortable with the command line. If not, somebody can write a GUI for easy_install/pip interfacing to pypi. Applications are expected to have a graphical installer, so a gui-version of zc.buildout then? (I'm only half serious). -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setuptools has divided the Python community
Lennart Regebro regebro at gmail.com writes: The people who use pythonlibraries are programmers. It can be expected that they are comfortable with the command line. You probably haven't met lots of Windows (so-called) programmers... Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
Greg Ewing wrote: Guido van Rossum wrote: But it's been answered already -- we can't change the meaning of StopIteration() with a value unequal to None, so it has to be a separate exception, and it should not derive from StopIteration. How about having StopIteration be a subclass of the new exception? Then things that want to get generator return values only have one exception to catch, and things that only know about StopIteration will fail to catch the new exception. I actually like that, because it means that coroutine-y code could pretty much ignore the existence of StopIteration (despite it existing first). It would also mean that it wouldn't matter if return and return None both raised StopIteration, since they would still be intercepted by GeneratorReturn exception handlers. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] package resources [was: setuptools has divided the Python community]
At 11:27 PM 3/26/2009 +, Paul Moore wrote: What I'd really like is essentially some form of virtual filesystem access to stuff addressed relative to a Python package name, P.J. Eby responded: Note that relative to a *Python package name* isn't quite as useful, due to namespace packages. To be unambiguous as to the targeted resource, one needs to be able to reference a specific project, and that requires you to go off the name of a module *within* a package. For example, 'zope.somemodule' rather than just 'zope'. I would expect it to be *most* important then. If I know for sure that an entire package is all together in a single directory, I can just use that directory. If I want all xxx files used by zope, then ... I *do* want information on the duplicates, and the multiple locations. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Are buffer overflows in modules deleted in py3k ignorable?
I'm reviewing http://bugs.python.org/issue2591, which is marked as 'security' because it is a potential buffer overflow. almodule.c has been dropped in py3k, so my impulse is to close the bug as won't fix. But I thought I should check in to find out what the policy is before doing that since it is a 'security' bug. -- R. David Murray http://www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
On Sat, Mar 28, 2009 at 8:14 PM, Nick Coghlan ncogh...@gmail.com wrote: Greg Ewing wrote: Guido van Rossum wrote: But it's been answered already -- we can't change the meaning of StopIteration() with a value unequal to None, so it has to be a separate exception, and it should not derive from StopIteration. How about having StopIteration be a subclass of the new exception? Then things that want to get generator return values only have one exception to catch, and things that only know about StopIteration will fail to catch the new exception. I actually like that, because it means that coroutine-y code could pretty much ignore the existence of StopIteration (despite it existing first). Okay. It would also mean that it wouldn't matter if return and return None both raised StopIteration, since they would still be intercepted by GeneratorReturn exception handlers. Well I already didn't care about that. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] suggestion for try/except program flow
Mark Donald wrote: I frequently have this situation: try: try: raise Thing except Thing, e: # handle Thing exceptions raise except: # handle all exceptions, including Thing This seems like an unusual pattern. Are you sure you can't use try: raise Thing except Thing, e: # handle Thing exceptions raise finally: # handle *all situations*, including Thing Obviously, the finally: block is also invoked in the case that no exceptions are triggered, but often this is what you want anyway... Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
