[Python-Dev] Distutils2 scripts
Hello, In the Distutils2 project, we'll have quite a few scripts that can be called via -m $ python -m distutils2.depgraph : shows a dependency graph $ python -m distutils2.install : installs a project $ python -m distutils2.run command : runs a distutils2 command etc.. The feedback I received for this is pretty clear: people want a single script that can be called directly. e.g. $ distutils2 depgraph $ distutils2 install $ distutils2 run command Fair enough, I can add that script in the project and get it installed when people install the project. I just wanted to make sure that once distutils2 is back in the stdlib, it's OK for us to add that script in the distribution. I remember that people did not want "yet another script" in there, so I just wanted to double-check before I take this path Thanks ! Tarek -- Tarek Ziadé | http://ziade.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
Re: [Python-Dev] python.org going down?
-On [20101008 01:22], "Martin v. Löwis" (mar...@v.loewis.de) wrote: >True. However, I really cannot see anything on the machines that >indicates some outage. I'm still unsure what "it" is that was happening, >so it's also difficult to analyse this further. It's hosted by XS4All, they had some network problems yesterday at least. I am not sure if it would explain this behaviour, might be one of the uplinks or peers had some issues. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Sleep tonight, sweet summer light, scattered yesterdays, the past is far away... ___ 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] Distutils2 scripts
-On [20101008 09:07], Tarek Ziadé (ziade.ta...@gmail.com) wrote: >The feedback I received for this is pretty clear: people want a single >script that can be called directly. e.g. > >$ distutils2 depgraph >$ distutils2 install >$ distutils2 run command +1 from me. I sincerely dislike the Perl-esque -m stuff. >I just wanted to make sure that once distutils2 is back in the stdlib, >it's OK for us to add that script in the distribution. No problem from my side, I do, however, not speak for the developers at large of course. ;) -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Care-charmer Sleep, son of the sable Night, Brother to Death, in silent darkness born... ___ 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] Distutils2 scripts
-On [20101008 09:07], Tarek Ziadé (ziade.ta...@gmail.com) wrote:
>I just wanted to make sure that once distutils2 is back in the stdlib,
>it's OK for us to add that script in the distribution.
Ah, one thing that came to mind:
is this script supposed to be installed in /usr{/local}/bin? If so, how
would it look like for multiple Python distributions that are installed?
--
Jeroen Ruigrok van der Werven / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
To the dull mind nature is leaden. To the illumined mind the whole world
burns and sparkles with light...
___
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] Distutils2 scripts
On Fri, Oct 8, 2010 at 9:25 AM, Jeroen Ruigrok van der Werven
wrote:
> -On [20101008 09:07], Tarek Ziadé (ziade.ta...@gmail.com) wrote:
>>I just wanted to make sure that once distutils2 is back in the stdlib,
>>it's OK for us to add that script in the distribution.
>
> Ah, one thing that came to mind:
>
> is this script supposed to be installed in /usr{/local}/bin? If so, how
> would it look like for multiple Python distributions that are installed?
This script will be installed besides the Python executable, so it
should follow the same naming rules depending on the OSes.
e.g. a -MINOR.MINOR suffix is appended *or* each python version has
its own bin/ location etc.
--
Tarek Ziadé | http://ziade.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
Re: [Python-Dev] Distutils2 scripts
On Fri, Oct 8, 2010 at 9:50 AM, Tarek Ziadé wrote: ... > e.g. a -MINOR.MINOR MAJOR.MINOR ___ 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] os.path.normcase rationale?
On 05/10/2010 12:04, Steven D'Aprano wrote: On Tue, 5 Oct 2010 07:21:15 pm Chris Withers wrote: On 25/09/2010 04:25, Steven D'Aprano wrote: 1. Return the case of a filename in some canonical form which depends on the file system? 2. Return the case of a filename as it is actually stored on disk? How do 1 and 2 differ? Case #1 imposes a particular canonical form, regardless of what is actually stored on disk. It is similar to normpath, except that we could have different canonical forms depending on what the file system was. normpath merely generalises from the operating system, and never looks at the file system. Ah, okay, yeah, that's actually an anti-goal for me ;-) Case #2 says to actually look at the file and see what the file system considers it's name to be. Consider a NTFS file system. By default it is case-preserving and case-insensitive, although that can be changed. (Just because a file system is NTFS doesn't mean that will be case-insensitive. NTFS can also run in a POSIX mode which is case-sensitive. But I digress.) Yeah, this is definitely where I think the missing use case lies... FWIW, the use case that setuptools has (and for which it currently incorrectly uses normpath) is number 2. 4. Return the case of a filename in some arbitrarily-chosen canonical form which does not depend on the file system? This is what normpath does, but only if you're on Windows ;-) Not quite. macpath.normcase() also lowercases the path. So does the module for OS/2. Interesting, since I develop on MacOS, Linux and Windows and only experienced the problem caused by setuptools normcase'ing distribution names on Windows. The MacOS case also isn't in the docs. In any case, Windows is not a file system. It is quite possible to have virtually any combination of case-destroying, case-preserving, -sensitive and -insensitive file systems on the one Windows system. Say, a FAT12 floppy, an NTFS partition, and an ext2 USB stick. Windows doesn't ship with native support for ext2, but that doesn't mean it can't be installed with third party drivers. yes, exactly! normpath pays no attention to any of this, and just lowercases the path. At least that's cheap, and consistent, even if it solves the wrong problem :) ...and creates a few more along the way ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] Adding Wing 4 project to
On 05/10/2010 13:00, Antoine Pitrou wrote: 3. stay with versioned project file names and rename 'python-wing.wpr' to 'python-wing3.wpr' (Option 3 could be done immediately of course.) Option 3 looks the most reasonable to me. I don't use Wing, but option 3 does seem most sensible. Explicit-rather-than-implicit-ly yours, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] Another relative imports question
Hi All, The new explicit relative import syntax is great. I wanted to relatively import a module. import .mymoduleinmypackage ...and got a SyntaxError in Python 2.6. I guess I need to do: from . import mymoduleinmypackage ...but it does feel weirdly asymetric that: from .mymoduleinmypackage import something ...while: import .mymoduleinmypackage mymoduleinmypackage.something ...does not. cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] os.path.normcase rationale?
On 08/10/2010 09:41, Chris Withers wrote: On 05/10/2010 12:04, Steven D'Aprano wrote: On Tue, 5 Oct 2010 07:21:15 pm Chris Withers wrote: On 25/09/2010 04:25, Steven D'Aprano wrote: [snip...] FWIW, the use case that setuptools has (and for which it currently incorrectly uses normpath) is number 2. 4. Return the case of a filename in some arbitrarily-chosen canonical form which does not depend on the file system? This is what normpath does, but only if you're on Windows ;-) Not quite. macpath.normcase() also lowercases the path. So does the module for OS/2. Interesting, since I develop on MacOS, Linux and Windows and only experienced the problem caused by setuptools normcase'ing distribution names on Windows. The MacOS case also isn't in the docs. Unless you're using Mac OS 9 you will be using posixpath and not macpath though. :-) Michael -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] [Pythonmac-SIG] sad state of OS X Python testing...
On Tue, 5 Oct 2010 10:08:59 -0700 Stephen Hansen wrote: > On Sat, Oct 2, 2010 at 1:37 PM, "Martin v. Löwis" wrote: > > > > I'm already running a Jython buildslave on an Intel Mac Pro which is > > > pretty underused - I'd be happy to run a CPython one there too, if > > > it'd be worthwhile. > > > > I think Bill was specifically after Snow Leopard - what system are you > > using? > > > > I have a fairly recent MacPro on Snow Leopard, which I keep consistently up > to date and its connected all the time. It has more capacity then I can > really find use for. Now that the buildbot is up, it is recommended that you try to investigate the failures (and the test_ttk_guionly crash), and that you create bugs reports on http://bugs.python.org for them. Thank you! 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] Distutils2 scripts
Am 08.10.2010 09:05, schrieb Tarek Ziadé: > Hello, > > In the Distutils2 project, we'll have quite a few scripts that can be > called via -m > > $ python -m distutils2.depgraph : shows a dependency graph > $ python -m distutils2.install : installs a project > $ python -m distutils2.run command : runs a distutils2 command > > etc.. What happened to "python setup.py action"? Or is this a step towards not requiring setup.py at all? > The feedback I received for this is pretty clear: people want a single > script that can be called directly. e.g. > > $ distutils2 depgraph > $ distutils2 install > $ distutils2 run command > > Fair enough, I can add that script in the project and get it installed > when people install the project. > > I just wanted to make sure that once distutils2 is back in the stdlib, > it's OK for us to add that script in the distribution. > I remember that people did not want "yet another script" in there, so > I just wanted to double-check before I take this path This is certainly preferable to memorizing the modules you can call with -m, because it's easier to provide help functions. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Another relative imports question
Am 08.10.2010 10:50, schrieb Chris Withers: > Hi All, > > The new explicit relative import syntax is great. > I wanted to relatively import a module. > > import .mymoduleinmypackage > > and got a SyntaxError in Python 2.6. > > I guess I need to do: > > from . import mymoduleinmypackage > > but it does feel weirdly asymetric that: > > from .mymoduleinmypackage import something > > while: > > import .mymoduleinmypackage > mymoduleinmypackage.something > > does not. The explanation is that everything that comes after "import" is thereafter usable as an identifier (or expression, in the case of dotted names) in code. ".mymodule" is not a valid expression, so the question would be how to refer to it. (This argument is weakened in the present of an "as" renaming, but I doubt you'd like to write import .mymodule as mymodule .) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Distutils2 scripts
On Fri, Oct 8, 2010 at 5:22 PM, Jeroen Ruigrok van der Werven wrote: > +1 from me. I sincerely dislike the Perl-esque -m stuff. -m is generally for developer utilities, or "incidental" utilities provided by modules that are mainly intended for use as library modules. It's also very handy for running stuff out of an uninstalled Python (such as an svn checkout). For actual end-user facing scripts, a proper script on the system path is a better option. 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] Distutils2 scripts
On Fri, Oct 8, 2010 at 09:05, Tarek Ziadé wrote: > The feedback I received for this is pretty clear: people want a single > script that can be called directly. e.g. > > $ distutils2 depgraph > $ distutils2 install > $ distutils2 run command > > Fair enough, I can add that script in the project and get it installed > when people install the project. It doesn't seem very nice to have a version in the script. Can we just call it distutils? Or py-dist? paint-it-some-other-color-ly yours, Dirkjan ___ 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] Distutils2 scripts
On Fri, Oct 08, 2010 at 01:24:09PM +0200, Dirkjan Ochtman wrote: > On Fri, Oct 8, 2010 at 09:05, Tarek Ziadé wrote: > > The feedback I received for this is pretty clear: people want a single > > script that can be called directly. e.g. > > > > $ distutils2 depgraph > > $ distutils2 install > > $ distutils2 run command > > > > Fair enough, I can add that script in the project and get it installed > > when people install the project. > > It doesn't seem very nice to have a version in the script. Can we just > call it distutils? Or py-dist? pypackage? ___ 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] Distutils2 scripts
On Fri, Oct 8, 2010 at 7:24 AM, Dirkjan Ochtman wrote: > It doesn't seem very nice to have a version in the script. Can we just > call it distutils? Or py-dist? If we go this route, then - "make altinstall" should include the version number in the name of *any* scripts it installs. - "make install" would then add links without the version numbers. This mirrors the name of the Python executable, so is likely as "right" as it's going to get (*if* we install separate scripts). Georg: > What happened to "python setup.py action"? Or is this a step towards > not requiring setup.py at all? I'm in favor of add a top-level setup module that can be invoked using "python -m setup ...". There will be three cases: - d2 projects without a setup.py, where this will invoke the module from the standard library, - d2 projects with a setup.py, where the local setup.py will be invoked, and - d1 projects, which always have a setup.py, which will be invoked. This would provide the most consistent story for package users, where the only command they'll need to remember (for Python versions with the setup module) will be python -m setup ... -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] os.path.normcase rationale?
On 08 Oct, 2010,at 11:38 AM, Michael Foord wrote: On 08/10/2010 09:41, Chris Withers wrote: 4. Return the case of a filename in some arbitrarily-chosen canonical form which does not depend on the file system? AFAIK this is what the function is supposed to do: return a platform-dependent canonical form of the filename. And that is hopelessly naive on modern systems, on both linux and OSX some file systems are case insensitive and others are not. The default for Linux is case sensitive, but some filesystems are not (VFAT, CIFS), and the default on OSX is case insensitive, but some filesystems are case sensitive (NFS, case sensitive HFS+)Ronald ___ 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] Distutils2 scripts
2010/10/8 Fred Drake : > Georg: >> What happened to "python setup.py action"? Or is this a step towards >> not requiring setup.py at all? > > I'm in favor of add a top-level setup module that can be invoked using > "python -m setup ...". There will be three cases: > > - d2 projects without a setup.py, where this will invoke the module from > the standard library, > > - d2 projects with a setup.py, where the local setup.py will be invoked, > and > > - d1 projects, which always have a setup.py, which will be invoked. > > This would provide the most consistent story for package users, where the > only command they'll need to remember (for Python versions with the setup > module) will be > > python -m setup ... That seems like a fairly elegant solution. Cheers, Dirkjan ___ 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] Distutils2 scripts
Am 08.10.2010 14:02, schrieb Fred Drake: > Georg: >> What happened to "python setup.py action"? Or is this a step towards >> not requiring setup.py at all? > > I'm in favor of add a top-level setup module that can be invoked using > "python -m setup ...". There will be three cases: > > - d2 projects without a setup.py, where this will invoke the module from > the standard library, > > - d2 projects with a setup.py, where the local setup.py will be invoked, > and > > - d1 projects, which always have a setup.py, which will be invoked. > > This would provide the most consistent story for package users, where the > only command they'll need to remember (for Python versions with the setup > module) will be > > python -m setup ... That's actually a very nice trick, *probably* together for a "shortcut" for "python -m setup". Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Distutils2 scripts
On Fri, Oct 8, 2010 at 12:24 PM, Georg Brandl wrote: > Am 08.10.2010 09:05, schrieb Tarek Ziadé: >> Hello, >> >> In the Distutils2 project, we'll have quite a few scripts that can be >> called via -m >> >> $ python -m distutils2.depgraph : shows a dependency graph >> $ python -m distutils2.install : installs a project >> $ python -m distutils2.run command : runs a distutils2 command >> >> etc.. > > What happened to "python setup.py action"? Or is this a step towards > not requiring setup.py at all? Yes, setup.py is gone and everything is driven by scripts, that read setup.cfg. There are some configurable hooks to call code when wanted bu the idea is that those are restricted to the build part of the process, so a release made at PyPI provides static metadata. Tarek -- Tarek Ziadé | http://ziade.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
Re: [Python-Dev] Distutils2 scripts
2010/10/8 Fred Drake : > On Fri, Oct 8, 2010 at 7:24 AM, Dirkjan Ochtman wrote: >> It doesn't seem very nice to have a version in the script. Can we just >> call it distutils? Or py-dist? > > If we go this route, then > > - "make altinstall" should include the version number in the name of *any* > scripts it installs. > > - "make install" would then add links without the version numbers. > > This mirrors the name of the Python executable, so is likely as "right" as > it's going to get (*if* we install separate scripts). Yes that what I was thinking about -- I am not too worried about this, since every Linux deals with the 'more than one python installed' case. > > Georg: >> What happened to "python setup.py action"? Or is this a step towards >> not requiring setup.py at all? > > I'm in favor of add a top-level setup module that can be invoked using > "python -m setup ...". There will be three cases: Nice idea ! I wouldn't call it setup though, since it does many other things. I can't think of a good name yet, but I'd like such a script to express the idea that it can be used to: - query pypi - browse what's installed - install/remove projects - create releases and upload them pkg_manager ? > > - d2 projects without a setup.py, where this will invoke the module from > the standard library, Yes ! > > - d2 projects with a setup.py, where the local setup.py will be invoked, > and Mmm.. setup.py is gone in D2, and setup.py will be the marker of d1. Some project might want to provide both setups for backward compatibility: - a setup.py (d1) - a setup,cfg (d2 and optionally some d1 options) It's easy enough in that case to detect if the .cfg has what d2 requires (like the [metadata] section) > > - d1 projects, which always have a setup.py, which will be invoked. Yes > > This would provide the most consistent story for package users, where the > only command they'll need to remember (for Python versions with the setup > module) will be > > python -m setup ... Nice ! And I'd like to extend this idea with what we said at the last Summit. What if a project like Pip is able to replace d1 and or d2 when it comes to install a package. As long as we agree on the same command line interface, we could provide a way for pip to be called by this global script. Tarek -- Tarek Ziadé | http://ziade.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
Re: [Python-Dev] Distutils2 scripts
On Fri, Oct 8, 2010 at 15:22, Tarek Ziadé wrote: > Mmm.. setup.py is gone in D2, and setup.py will be the marker of d1. So, sorry for backing up to this, but isn't it true that many projects do custom stuff in their setup.py that they wouldn't be able to do in setup.cfg? Is the goal really to make that impossible/unnecessary? In Mercurial, for example, we have a fairly large setup.py that helps us deal with many kinds of issues: incomplete Python installations on different platforms, adding packages depending on the platform, do custom stuff to compile gettext files, etc... Cheers, Dirkjan ___ 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] Distutils2 scripts
On 08/10/2010 14:28, Dirkjan Ochtman wrote: On Fri, Oct 8, 2010 at 15:22, Tarek Ziadé wrote: Mmm.. setup.py is gone in D2, and setup.py will be the marker of d1. So, sorry for backing up to this, but isn't it true that many projects do custom stuff in their setup.py that they wouldn't be able to do in setup.cfg? Is the goal really to make that impossible/unnecessary? The goal is to make it unnecessary. My understanding is that it will still be possible to use a setup.py, just unnecessary for the vast majority of cases. All the best, Michael In Mercurial, for example, we have a fairly large setup.py that helps us deal with many kinds of issues: incomplete Python installations on different platforms, adding packages depending on the platform, do custom stuff to compile gettext files, etc... Cheers, Dirkjan ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Distutils2 scripts
On Fri, Oct 8, 2010 at 3:28 PM, Dirkjan Ochtman wrote: > On Fri, Oct 8, 2010 at 15:22, Tarek Ziadé wrote: >> Mmm.. setup.py is gone in D2, and setup.py will be the marker of d1. > > So, sorry for backing up to this, but isn't it true that many projects > do custom stuff in their setup.py that they wouldn't be able to do in > setup.cfg? They will still be able to do it by using hooks. > Is the goal really to make that impossible/unnecessary? In > Mercurial, for example, we have a fairly large setup.py that helps us > deal with many kinds of issues: incomplete Python installations on > different platforms, adding packages depending on the platform, do > custom stuff to compile gettext files, etc... No the goal is to stop having setup.py as the standard for getting metadata from a project. There will always be ways to call some code in the various steps. setup.py is currently called for everything : building, installing, providing metadata etc. We want to break that and make it possible for people to express their metadata into a static file, and offer ways to express them differently depending on the platforms. See PEP 345. So you should have what you need. Now, we are still in early stages in providing these features, and I'd be happy to work on the Mercurial setup.py conversion, if it's a complex use case. So we can see how things go. Tarek > > Cheers, > > Dirkjan > -- Tarek Ziadé | http://ziade.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
Re: [Python-Dev] Distutils2 scripts
2010/10/8 Michael Foord : > On 08/10/2010 14:28, Dirkjan Ochtman wrote: >> >> On Fri, Oct 8, 2010 at 15:22, Tarek Ziadé wrote: >>> >>> Mmm.. setup.py is gone in D2, and setup.py will be the marker of d1. >> >> So, sorry for backing up to this, but isn't it true that many projects >> do custom stuff in their setup.py that they wouldn't be able to do in >> setup.cfg? Is the goal really to make that impossible/unnecessary? > > The goal is to make it unnecessary. My understanding is that it will still > be possible to use a setup.py, just unnecessary for the vast majority of > cases. Yes. And to make it possible to keep a d1 setup.py, which works with all installers out there, we decided that d2 would ignore that file, and provide other ways to hook code if necessary. IOW one project may provide a d1 setup.py and a d2 configuration in the same release. > > All the best, > > Michael > >> In >> Mercurial, for example, we have a fairly large setup.py that helps us >> deal with many kinds of issues: incomplete Python installations on >> different platforms, adding packages depending on the platform, do >> custom stuff to compile gettext files, etc... >> >> Cheers, >> >> Dirkjan >> ___ >> 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/fuzzyman%40voidspace.org.uk > > > -- > > http://www.voidspace.org.uk/ > > READ CAREFULLY. By accepting and reading this email you agree, > on behalf of your employer, to release me from all obligations > and waivers arising from any and all NON-NEGOTIATED agreements, > licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, > confidentiality, non-disclosure, non-compete and acceptable use > policies (”BOGUS AGREEMENTS”) that I have entered into with your > employer, its partners, licensors, agents and assigns, in > perpetuity, without prejudice to my ongoing rights and privileges. > You further represent that you have the authority to release me > from any BOGUS AGREEMENTS on behalf of your employer. > > -- Tarek Ziadé | http://ziade.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
Re: [Python-Dev] Patch making the current email package (mostly) support bytes
On Oct 08, 2010, at 12:37 PM, Stephen J. Turnbull wrote: >Ouch. RFC 822 line wrapping is a bytes->bytes transformation, and the >client shouldn't see it at all unless it inspects the wire format. Header wrapping sucks even more because it's supposed to take the semantic context into account, which means that a generic Header wrapping algorithm cannot work for everything. E.g. Received: headers are supposed to wrap after the semicolon. The current email package does a pretty poor job of emulating this requirement, though it often gets it right enough. David has plans for addressing this problem. -Barry signature.asc Description: 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] Distutils2 scripts
On Oct 08, 2010, at 03:22 PM, Tarek Ziadé wrote: >Yes that what I was thinking about -- I am not too worried about this, >since every Linux deals with the 'more than one python installed' >case. Kind of. but anyway... >> I'm in favor of add a top-level setup module that can be invoked using >> "python -m setup ...". There will be three cases: > >Nice idea ! I wouldn't call it setup though, since it does many other >things. I can't think of a good name yet, but I'd like such a script >to express the idea that it can be used to: I like 'python -m setup' too. It's a small step from the familiar thing (python setup.py) to the new and shiny thing, without being confusing. And you won't have to worry about things like version numbers because the Python executable will already have that baked in. >- query pypi >- browse what's installed >- install/remove projects >- create releases and upload them > >pkg_manager ? No underscores, please. :) Actually, a decent wrapper script could just be called 'setup'. My command-not-found on Ubuntu doesn't find a collision, or even close similarities. I still like 'egg' as a command too. There are no collisions that I can see. I know this has been thrown around for years, and it's always been rejected because I think setuptools wanted to claim it, but since it still doesn't exist afaict, distutils2 could easily use it. In any case, these could be a simple shell script wrapping 'python -m setup'. It could even take a --use-python-version option to select the pythonX.Y it used, without having to encode the Python version number in the script name. -Barry signature.asc Description: 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] [Pythonmac-SIG] sad state of OS X Python testing...
On Fri, Oct 8, 2010 at 2:42 AM, Antoine Pitrou wrote: > On Tue, 5 Oct 2010 10:08:59 -0700 > Stephen Hansen wrote: > > On Sat, Oct 2, 2010 at 1:37 PM, "Martin v. Löwis" >wrote: > > > > > > I'm already running a Jython buildslave on an Intel Mac Pro which is > > > > pretty underused - I'd be happy to run a CPython one there too, if > > > > it'd be worthwhile. > > > > > > I think Bill was specifically after Snow Leopard - what system are you > > > using? > > > > > > > I have a fairly recent MacPro on Snow Leopard, which I keep consistently > up > > to date and its connected all the time. It has more capacity then I can > > really find use for. > > Now that the buildbot is up, it is recommended that you try to > investigate the failures (and the test_ttk_guionly crash), and that you > create bugs reports on http://bugs.python.org for them. > I shall, I just got busy yesterday. :) The failure is happening just because it can't possibly succeed, I set up the account for the buildbot in such a way that it has no access to a GUI context. I'm going to rectify that today so I can properly test TK. The hard crash I'll report as soon as I have a few minutes to isolate more where its happening and thus to who all should get a report. --Stephen ___ 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] Distutils2 scripts
Am 08.10.2010 16:26, schrieb Barry Warsaw: >>- query pypi >>- browse what's installed >>- install/remove projects >>- create releases and upload them >> >>pkg_manager ? > > No underscores, please. :) > > Actually, a decent wrapper script could just be called 'setup'. My > command-not-found on Ubuntu doesn't find a collision, or even close > similarities. No generic name, *please*. easy_install was bad enough, no need to repeat that mistake. "egg" would be better, but weren't we phasing out the egg format? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] [Pythonmac-SIG] sad state of OS X Python testing...
Hi, > The failure is happening just because it can't possibly succeed, I set > up the account for the buildbot in such a way that it has no access to > a GUI context. I'm going to rectify that today so I can properly test > TK. Well, a nice thing would be for tests to be properly skipped in this situation, rather than fail or crash :) Do you think you can try to write a patch for this? Thanks for helping! ___ 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] Distutils2 scripts
On Fri, 8 Oct 2010 10:26:36 -0400 Barry Warsaw wrote: > >- query pypi > >- browse what's installed > >- install/remove projects > >- create releases and upload them > > > >pkg_manager ? > > No underscores, please. :) > > Actually, a decent wrapper script could just be called 'setup'. My > command-not-found on Ubuntu doesn't find a collision, or even close > similarities. pysetup perhaps? I think "setup" is such a generic name that being a Python-specific tool sounds wrong. I also had that reaction towards easy_install at the beginning. > I still like 'egg' as a command too. There are no collisions that I can see. > I know this has been thrown around for years, and it's always been rejected > because I think setuptools wanted to claim it, but since it still doesn't > exist afaict, distutils2 could easily use it. 'egg' is already the name of a file format, so re-using that name for something more general would be confusing. What would you think if 'tar' allowed you to resize JPEGs? :) ___ 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] Distutils2 scripts
On Fri, Oct 08, 2010 at 10:26:36AM -0400, Barry Warsaw wrote: > On Oct 08, 2010, at 03:22 PM, Tarek Ziadé wrote: > > >Yes that what I was thinking about -- I am not too worried about this, > >since every Linux deals with the 'more than one python installed' > >case. > > Kind of. but anyway... > > >> I'm in favor of add a top-level setup module that can be invoked using > >> "python -m setup ...". There will be three cases: > > > >Nice idea ! I wouldn't call it setup though, since it does many other > >things. I can't think of a good name yet, but I'd like such a script > >to express the idea that it can be used to: > > I like 'python -m setup' too. It's a small step from the familiar thing > (python setup.py) to the new and shiny thing, without being confusing. And > you won't have to worry about things like version numbers because the Python > executable will already have that baked in. > > >- query pypi > >- browse what's installed > >- install/remove projects > >- create releases and upload them > > > >pkg_manager ? > > No underscores, please. :) > > Actually, a decent wrapper script could just be called 'setup'. My > command-not-found on Ubuntu doesn't find a collision, or even close > similarities. > Simple English names like this are almost never a good idea for commands. A quick google for "/usr/bin/setup" finds that Fedora-derived distros have a /usr/bin/setup as a wrapper for all the text-mode configuration tools. And there's a derivative of opensolaris that has a /usr/bin/setup for configuring the system the first time. > I still like 'egg' as a command too. There are no collisions that I can see. > I know this has been thrown around for years, and it's always been rejected > because I think setuptools wanted to claim it, but since it still doesn't > exist afaict, distutils2 could easily use it. > There's a 2D graphics library that provides a /usr/bin/egg command: http://www.ir.isas.jaxa.jp/~cyamauch/eggx_procall/ Latest Stable Version 0.93r3 (released 2010/4/14) In the larger universe of programs, it might make for more intuitive remembering of the command to use a prefix (either py or python) though. python-setup is a lot like python setup.py pysetup is shorter pyegg is even shorter :-) -Toshio pgpVyH77xDEyw.pgp Description: 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] Patch making the current email package (mostly) support bytes
Barry Warsaw writes:
> Header wrapping sucks even more because it's supposed to take the
> semantic context into account, which means that a generic Header
> wrapping algorithm cannot work for everything. E.g. Received:
> headers are supposed to wrap after the semicolon.
Received headers are an easy special case:
An Internet mail program MUST NOT change or delete a Received:
line that was previously added to the message header section.
(RFC 5321, sec. 4.4)
So you save them as bytes and Barry's your FLUFL, as they say.
If email wants to *produce* them (as a service to say smtplib), then
it wants to comply with the detailed recommendations in RFC 5321,
sec. 4.4 anyway; I don't think there's a good reason treat Received
headers as text since they're conceptually part of the wire protocol.
(Except for the information of curious users, but then getting it
exactly right is best done by just passing the whole thing, folds and
all, to .decode('ascii'), I should think.)
I should think you *want* addresses and suchlike structured headers
(Content-Type with several RFC 2231 parameters, anyone?) to line up
nicely, too. So generic folding algorithms are really only applicable
to unstructured text fields like Subject and Summary anyway.
You can call that "sucky" if you like, I prefer to call it "tasteful."
___
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] Distutils2 scripts
On Oct 08, 2010, at 11:04 AM, Toshio Kuratomi wrote: >python-setup is a lot like python setup.py >pysetup is shorter >pyegg is even shorter :-) wfm! -Barry signature.asc Description: 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] [Pythonmac-SIG] sad state of OS X Python testing...
On Fri, Oct 8, 2010 at 8:00 AM, Antoine Pitrou wrote: > > Hi, > > > The failure is happening just because it can't possibly succeed, I set > > up the account for the buildbot in such a way that it has no access to > > a GUI context. I'm going to rectify that today so I can properly test > > TK. > > Well, a nice thing would be for tests to be properly skipped in this > situation, rather than fail or crash :) Do you think you can try to > write a patch for this? > Absolutely, that's on my TODO list. First, figuring out the buildslave control process; then isolating where that crash is happening and reporting it to whomever (which, I think in a cursory look, is actually the TK folks); then figuring out how to convert no-GUI-context-possible situations into a skip. --S ___ 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] Distutils2 scripts
On Fri, 8 Oct 2010 11:04:35 -0400 Toshio Kuratomi wrote: > > In the larger universe of programs, it might make for more intuitive > remembering of the command to use a prefix (either py or python) though. > > python-setup is a lot like python setup.py > pysetup is shorter > pyegg is even shorter :-) Wouldn't "quiche" be a better alternative for "pyegg"? ___ 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] Distutils2 scripts
On 08/10/2010 16:07, Barry Warsaw wrote:
On Oct 08, 2010, at 11:04 AM, Toshio Kuratomi wrote:
python-setup is a lot like python setup.py
pysetup is shorter
pyegg is even shorter :-)
wfm!
To avoid any potential confusion, wfm is a common tla for the following
phrases:
Whole Foods Market
Western Federation of Miners
Window Fitters Mate
Workforce Management
Although wfm is possibly being used here as "works for me" given the
context... ;-)
Michael
-Barry
___
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/fuzzyman%40voidspace.org.uk
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies ("BOGUS AGREEMENTS") that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.
___
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] Distutils2 scripts
On Fri, Oct 08, 2010 at 11:04:35AM -0400, Toshio Kuratomi wrote: > In the larger universe of programs, it might make for more intuitive > remembering of the command to use a prefix (either py or python) though. > > python-setup is a lot like python setup.py > pysetup is shorter > pyegg is even shorter :-) I'd just like to say "pypackage" again. pypackage install thingy pypackage remove thingy pypackage update thingy etc ___ 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] Patch making the current email package (mostly) support bytes
Thanks for both your reply and work, David. I'm going to have to test my email clients under the 3.2 patch when it gels. It's good to hear that email5 API support remains a goal. I don't mean to single out this change unfairly, of course. My real concern is not as much with the specific technical aspects of this proposal, as with the generally low priority that backward compatibility sometimes receives on this list. The bytecode file model change in 3.2 comes to mind as another example; sound as it may be, I'm not sure this list has any idea how many users, systems, or docs may be impacted by this. Though not always true, the work here does sometimes appear to be conducted in a vacuum. Ultimately, development in the open source world is driven by the very few with time to show up, rather than by the very many who depend on it. This can unfortunately lead to the perception of thrashing by end users. Some even come to see the net effect as not that much different from closed models. I have no solution to offer, except to underscore again that changes made here affect very many people who are too busy using Python to participate here. Especially given the still tentative state of 3.X, stability matters. --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) > -Original Message- > From: "R. David Murray" > To: l...@rmi.net > Subject: Re: [Python-Dev] Patch making the current email package (mostly) > support bytes > Date: Thu, 07 Oct 2010 13:46:02 -0400 > > On Thu, 07 Oct 2010 16:03:18 -, l...@rmi.net wrote: > > I'm forwarding a link to the code of these clients to David by > > private email in case they might be useful as a test case (O'Reilly > > has already posted them ahead of the book, but they may be a bit too > > heavy for use in formal testing). > > Thanks very much. I will take a look, and expect they will > be helpful. > > > The email package is obviously less than ideal today, and there are > > many other clients for it besides my own, of course. But making it > > backward incompatible at this point is likely to be seen as a big > > negative to newcomers evaluating 3.X viability. And as I tried to > > make clear in June, this list should carefully weigh the PR cost of > > pulling the rug out from under those brave souls who have already > > taken the time to accommodate the 3.X world you've mandated. > > Well, as I have said before the plan is to provide backward compatibility > in email6, so that you only need to change your code if you want to > take advantage of improved or new functionality. If this turns out not > to be possible for some reason, then we aren't going to suddenly stop > supporting email5. That's not the Python Way :) (Example: we added > ArgParse post-3.0, and lots of people wanted to deprecate OptParse, > but we aren't planning on removing OptParse.) > > Do you see any issues with the patch I'm proposing? My goal is to make > things work that didn't work before, but nothing that worked before > should stop working, if I do my job right. > > The one *potentially* backward-incompatible change that I'm consciously > considering (that is, any other backward incompatibilities will be bugs) > is having DecodedGenerator fully decode headers and emit full unicode, > rather than the ASCII-only unicode that Generator emits. Can you think > of any problem that that would cause? A quick grep indicates your own > code does not use that generator (possibly because currently it does not > do that decoding). I could, of course, only enable header decoding if > a flag is passed requesting it, and as I write this I realize that that > is indeed what I should do. Even though I haven't been able to think of a > case where DecodedGenerator producing non-ASCII unicode would be an issue, > that doesn't mean there isn't one :) > > > To put that more strongly, the Python user base is much larger than > > this list's readership. If I'm using 3.1 email, so are many others. > > People will accept the 3.X world you make up to a point, but it's > > impossible to code to a moving target, much less base a product on > > it. At some point, they'll simply stop trying to keep up; in fact, > > some already have. > > > > Fixes are a Good Thing, of course, and this particular change's scope > > remains to be seen; but to channel most of the users I meet out there > > in the real world today: Enough with the 3.X changes already, eh? > > Now that Python3 is out, the backward compatibility policy for it is > the same as it always was for Python2. Only the transition from 2 > to 3 broke backward compatibility in a significant way. From here > on, we are as conservative as we always have been at making backward > incompatible changes (that is, we don't do it intentionally without > a good reason and a deprecation cycle, and if we do it unintentionally > it is a regression and treated as such). > > -- > R. David Murray
Re: [Python-Dev] Patch making the current email package (mostly) support bytes
step...@xemacs.org wrote in the full message below: > If having 1 *and* 2 is so important to particular users, but they come > into conflict because of proposed changes in Python, then they're > going to have to give up 3, come here, and articulate their needs. But I _did_ come here and articulate my needs, and received this antagonistic response for my efforts. If you really value user input, you may want to explore the nature of your reaction to it. Trust me: criticism goes with the territory any time your actions impact a large group of people. This seems inherent here. Frankly, your view of the roles of developers and users seems so upside down to me that I doubt anything I could say here would matter. You're more than welcome to ignore an interjection of reality and adopt a closed group mindset, of course, but you do so at the peril of the system you're working on. For my part, one week from now I'll be standing up again in front of a group of 20 Python beginners, and basically apologizing for both the present and ongoing 3.X changes they must conform to in the near future. Python may not be Perl 6 yet, but its image is already tarnished in the real world where people make technology choices, due to its rapid pace of change. It's a genuine problem. In the end, I suppose I'm just one of those lazy end users you mentioned who are too busy to spend 24/7 hanging out on this list in order to head off changes that will break their code. (Yes, sarcasm intended.) --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) > -Original Message- > From: "Stephen J. Turnbull" > To: l...@rmi.net > Subject: Re: [Python-Dev] Patch making the current email package > (mostly)support bytes > Date: Fri, 08 Oct 2010 14:33:22 +0900 > > l...@rmi.net writes: > > > To put that more strongly, the Python user base is much larger than > > this list's readership. > > Agreed. Nevertheless, this is the channel (not "channel") that the > developers listen on, and substantial effort is made to let Python > users know that. I think they do know it, too. > > > If I'm using 3.1 email, so are many others. > > That's not obvious. 3.1 email is unusable for several applications. > In fact, for human factors reasons (humans are very likely to > communicate with other humans who use the same encodings, and to > accept occasional glitches they must deal with manually), MUAs are > likely to port relatively easily as "good enough" software. But I > doubt very much that folks writing MTAs or spam filters that must run > unattended, often in long-lived, very active processes, are producing > production versions using Python 3 email yet. > > > People will accept the 3.X world you make up to a point, but it's > > impossible to code to a moving target, much less base a product on > > it. > > "Impossible is nothing." It's a decision that each individual > developer makes for herself. I haven't heard Mailman devs complain > about the impossibility of dealing with the proposed changes, for > example. Quite the reverse, in fact. > > > At some point, they'll simply stop trying to keep up; in fact, > > some already have. > > Predictable and predicted. Where's the balance? I don't know, but > "channeling" the users is not a lot of help. There are three worthy > goals here: > > 1. Taking advantage of improvements in to-be-released Pythons. > 2. Not changing one's own working code. > 3. Not participating in python-dev/email-sig. > > Take any two; one can't have all three. > > More specifically, it's interesting that most of the users you talk to > care enough to actually say they don't want more incompatible changes. > But what are we supposed to take from that? Some fixes have to be > incompatible; do the users want the fix or the compatibility? You > waffle (as a good representative often must): > > > Fixes are a Good Thing, of course, and this particular change's scope > > remains to be seen; but to channel most of the users I meet out there > > in the real world today: Enough with the 3.X changes already, eh? > > But that's also a decision each developer *can* make for himself. > Python does not withdraw products, or even withdraw support, just > because the core developers release something they consider better. > > If having 1 *and* 2 is so important to particular users, but they come > into conflict because of proposed changes in Python, then they're > going to have to give up 3, come here, and articulate their needs. As > you are doing -- but to have real influence, you're going to have to > do the review of David's patch that he requests. > > I really don't see how the process can work any other way. > ___ 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] Distutils2 scripts
On Fri, Oct 08, 2010 at 05:12:44PM +0200, Antoine Pitrou wrote: > On Fri, 8 Oct 2010 11:04:35 -0400 > Toshio Kuratomi wrote: > > > > In the larger universe of programs, it might make for more intuitive > > remembering of the command to use a prefix (either py or python) though. > > > > python-setup is a lot like python setup.py > > pysetup is shorter > > pyegg is even shorter :-) > > Wouldn't "quiche" be a better alternative for "pyegg"? > I won't bikeshed as long as we stay away from conflicting names. -Toshio pgpk9LAmigC2q.pgp Description: 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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-10-01 - 2010-10-08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues stats: open2557 (+37) closed 19276 (+30) total 21833 (+44) Open issues with patches: 1071 Issues opened (37) == #10008: Two links point to same place http://bugs.python.org/issue10008 opened by ocean-city #10009: Automated MSI installation does not work http://bugs.python.org/issue10009 opened by amaury.forgeotdarc #10011: `except` doesn't use `isinstance` http://bugs.python.org/issue10011 opened by cool-RR #10013: fix `./libpython2.6.so: undefined reference to `_PyParser_Gram http://bugs.python.org/issue10013 opened by PaulePanter #10014: sys.path[0] is incorrect if PYTHONFSENCODING is used http://bugs.python.org/issue10014 opened by haypo #10015: Creating a multiproccess.pool.ThreadPool from a child thread b http://bugs.python.org/issue10015 opened by Michael.Olson #10016: shutil.copyfile -- allow sparse copying http://bugs.python.org/issue10016 opened by karaken12 #10017: pprint.pprint raises TypeError on dictionaries with user-defin http://bugs.python.org/issue10017 opened by arno #10018: IDLE not loading in xp pro due to tcl issue http://bugs.python.org/issue10018 opened by Grant.Andrew #10019: json.dumps with indent = 0 not adding newlines http://bugs.python.org/issue10019 opened by dpjanes #10020: docs for sqlite3 describe functions not available without reco http://bugs.python.org/issue10020 opened by doughellmann #10021: Format parser is too permissive http://bugs.python.org/issue10021 opened by belopolsky #10022: Emit more information in decoded SSL certificates http://bugs.python.org/issue10022 opened by pitrou #10023: test_lib2to3 leaks under 3.1 http://bugs.python.org/issue10023 opened by pitrou #10024: Outdated advice in C-API tutorial? http://bugs.python.org/issue10024 opened by pitrou #10025: random.seed not initialized as advertised http://bugs.python.org/issue10025 opened by goddard #10027: os.lstat/os.stat don't set st_nlink on Windows http://bugs.python.org/issue10027 opened by brian.curtin #10028: test_concurrent_futures fails on Windows Server 2003 http://bugs.python.org/issue10028 opened by brian.curtin #10029: "Equivalent to" code for zip is wrong in Python 3 http://bugs.python.org/issue10029 opened by max #10030: Patch for zip decryption speedup http://bugs.python.org/issue10030 opened by shashank #10031: Withdraw anti-recommendation of relative imports from document http://bugs.python.org/issue10031 opened by dsdale24 #10036: compiler warnings for various modules on Ubuntu x86 http://bugs.python.org/issue10036 opened by jfinkels #10037: multiprocessing.pool processes started by worker handler stops http://bugs.python.org/issue10037 opened by asksol #10038: Returntype of json.loads() on strings http://bugs.python.org/issue10038 opened by llnik #10039: python é.py fails with UnicodeEncodeError if PYTHONFSENCODING http://bugs.python.org/issue10039 opened by haypo #10040: GZipFile failure on large files http://bugs.python.org/issue10040 opened by Robert.Rohde #10041: socket.makefile(mode = 'r').readline() silently removes carria http://bugs.python.org/issue10041 opened by kaizhu #10042: total_ordering stack overflow http://bugs.python.org/issue10042 opened by francescor #10043: UnboundLocalError with local variable set by setattr, caused b http://bugs.python.org/issue10043 opened by ssc #10044: small int optimization http://bugs.python.org/issue10044 opened by pitrou #10045: poor cStringIO.StringO seek performance http://bugs.python.org/issue10045 opened by boogenhagn #10046: Correction to atexit documentation http://bugs.python.org/issue10046 opened by Jason.Baker #10047: python-2.6.6 coredump running newspipe http://bugs.python.org/issue10047 opened by wiz #10048: urllib.request documentation confusing http://bugs.python.org/issue10048 opened by pitrou #10049: Add a "no-op" (null) context manager to contextlib http://bugs.python.org/issue10049 opened by hniksic #10050: urllib.request still has old 2.x urllib primitives http://bugs.python.org/issue10050 opened by pitrou #10051: distutils fail to install unicode-encoded files with POSIX loc http://bugs.python.org/issue10051 opened by mgorny Most recent 15 issues with no replies (15) == #10051: distutils fail to install unicode-encoded files with POSIX loc http://bugs.python.org/issue10051 #10050: urllib.request still has old 2.x urllib primitives http://bugs.python.org/issue10050 #10048: urllib.request documentation confusing http://bugs.python.org/issue10048 #10039: python é.py fails with UnicodeEncodeError if PYTHONFSENCODING http://bugs.python.org/issue10039 #10037: multiprocessing.pool processes started by worker handler stops http://bugs.python.org/issue10037 #10036: compiler war
Re: [Python-Dev] Distutils2 scripts
Le 08/10/2010 17:31, Jon Ribbens a écrit : > I'd just like to say "pypackage" again. In the Python world, a package is a directory with an __init__.py file. Distutils and distutils2 try to avoid confusion and call the other things “distributions”. Of course, everyone outside of the Python world thinks a distribution is an operating system that has a free kernel and a package manager. Maybe we should trade “distributions” for “bundles”. Regards ___ 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] Patch making the current email package (mostly) support bytes
Barry Warsaw writes: > On Oct 07, 2010, at 04:40 AM, Stephen J. Turnbull wrote: > I'm fairly certain that most of the modern causes of [Unicode > errors in Mailman] are post-parse modifications of the message. > IOW, in Mailman's architecture, we try to parse the raw data into a > Message object tree very early in the pipeline, and then a pickled > version of that gets passed between the queue runners. > > Where we've gotten into trouble before has been things like adding > the Subject prefixes and such. Not to mention those wonderful unremovable addresses containing TAB etc. But I'm pretty sure I've seen reports at least in 2.1.9, and probably more recently than that, where there was 8-bit content in a header of the incoming message and Mailman blew up on that. This is stuff that should have been shunted explicitly, but instead managed to get out of the parser and then blow up. I don't think the errors I'm thinking about were due to Mailman manipulations, but rather insufficient paranoia in handling incoming hazmat. > That seems like application logic that the email package can't > really get involved with, and indeed Mailman has built up a raft of > defense for failures of this kind. But adding Subject prefixes and the like shouldn't be a problem as long is the internal representation of each message object (bytes vs str) is fixed and the representation is opaque, so that the module can do appropriate conversions when necessary. The problem that you face in Python 2 is that that separation is not properly made, and the same values in the message object can often serve as text and as wire format, and it's hard to tell which is which. The Unicode handling is tacked on as an afterthought. That mess is entirely unnecessary in Python 3. Text and wire format can be easily distinguished with three different representations of email: Unicode for the conceptual RFC 822 layer (of course this is an extension, because RFC 822 itself is strictly limited to the ASCII subset), bytes for wire format, and Message objects for modern structured mail (including MIME, etc). *If* email6 is reengineered with that kind of structure, then you should be able to dispense with almost all of the raft of defense, because the email module will give you well-behaved Message objects, whose text components (including the header) are well-behaved character strings that mix seamlessly with other character strings. Maybe even in email5 ___ 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] Distutils2 scripts
On Fri, Oct 8, 2010 at 4:54 PM, Georg Brandl wrote: > Am 08.10.2010 16:26, schrieb Barry Warsaw: > >>>- query pypi >>>- browse what's installed >>>- install/remove projects >>>- create releases and upload them >>> >>>pkg_manager ? >> >> No underscores, please. :) >> >> Actually, a decent wrapper script could just be called 'setup'. My >> command-not-found on Ubuntu doesn't find a collision, or even close >> similarities. > > No generic name, *please*. easy_install was bad enough, no need to repeat > that mistake. "egg" would be better, but weren't we phasing out the egg > format? -1 on anything containing the word 'egg'. It'll add confusion with egg-the-format > > Georg > > > -- > Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. > Four shall be the number of spaces thou shalt indent, and the number of thy > indenting shall be four. Eight shalt thou not indent, nor either indent thou > two, excepting that thou then proceed to four. Tabs are right out. > > ___ > 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/ziade.tarek%40gmail.com > -- Tarek Ziadé | http://ziade.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
Re: [Python-Dev] Distutils2 scripts
On Fri, Oct 8, 2010 at 5:53 PM, Toshio Kuratomi wrote: > On Fri, Oct 08, 2010 at 05:12:44PM +0200, Antoine Pitrou wrote: ... >> > pysetup is shorter Let's use pysetup ! ... > I won't bikeshed as long as we stay away from conflicting names. +1. So. Let's add pysetup in distutils2, that will be installed as a classical script. Once we move distutils2 back in the stdlib, it will be provided in Python's bin dir, so people will have the same "pysetup" name everywhere, Tarek -- Tarek Ziadé | http://ziade.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
Re: [Python-Dev] Distutils2 scripts
Le 10/08/2010 05:25 PM, Tarek Ziadé a écrit : > On Fri, Oct 8, 2010 at 5:53 PM, Toshio Kuratomi wrote: >> On Fri, Oct 08, 2010 at 05:12:44PM +0200, Antoine Pitrou wrote: > ... pysetup is shorter > > Let's use pysetup ! +1 on pysetup. Reusing the well known "setup" and adding py as a prefix will avoid any conflict. > > ... >> I won't bikeshed as long as we stay away from conflicting names. > > +1. > > So. Let's add pysetup in distutils2, that will be installed as a > classical script. Once we move distutils2 back in the stdlib, it will > be provided in Python's bin dir, so people will have the same > "pysetup" name everywhere, > > > 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] Distutils2 scripts
Le 10/08/2010 04:31 PM, Jon Ribbens a écrit : > On Fri, Oct 08, 2010 at 11:04:35AM -0400, Toshio Kuratomi wrote: >> In the larger universe of programs, it might make for more intuitive >> remembering of the command to use a prefix (either py or python) though. >> >> python-setup is a lot like python setup.py >> pysetup is shorter >> pyegg is even shorter :-) > > I'd just like to say "pypackage" again. > > pypackage install thingy > pypackage remove thingy > pypackage update thingy Btw, we are not talking about "packages", as packages are already used in the python concepts (See http://guide.python-distribute.org/glossary.html) So, it would be better to have something like "pydist", but seems to be less obvious than "pysetup". Alexis > > etc > ___ > 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/alexis%40notmyidea.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
Re: [Python-Dev] Patch making the current email package (mostly) support bytes
On Fri, 08 Oct 2010 15:51:45 -, l...@rmi.net wrote: > For my part, one week from now I'll be standing up again in front > of a group of 20 Python beginners, and basically apologizing for > both the present and ongoing 3.X changes they must conform to in > the near future. Python may not be Perl 6 yet, but its image is > already tarnished in the real world where people make technology > choices, due to its rapid pace of change. It's a genuine problem. > > In the end, I suppose I'm just one of those lazy end users you > mentioned who are too busy to spend 24/7 hanging out on this > list in order to head off changes that will break their code. > (Yes, sarcasm intended.) What would be helpful would be to know what changes it is that we have made between 3.1 and 3.2 that are raising backward compatibility concerns. What are we doing that is perceived as "ongoing 3.X changes"? Generalities will not help, only by looking at specifics can we re-evaluate our actions. In a private message you mentioned "the bytecode file model change", by which I presume you mean PEP 3147. Our view is that this is a backward compatible change: any Python program that was working should continue to work. Barry's original idea was that the new behavior would only be turned on by a flag, but Guido (and others) wanted it to be the default because in his view it is a superior arrangement for normal use. Perhaps we did not fully consider the effect on third party tools (and, as you point out, documentation) that expects .pyc files along side the .py files. Yet this change is no where near the level of change that makes typical Python programs fail. We feel like it is a worthwhile trade-off (and Debian and Ubuntu at least may well backport it to earlier Python versions). But apparently you disagree. So, engage us in dialog about it, please. And *please* mention any other specific changes you think are disruptive between 3.1 and 3.2. We need to know about them, preferably *before* we release 3.2 beta (currently targeted for the end of this month). Because I assure you that it is not our policy to be changing things any more rapidly than we did between python 2.x versions[*]. If you feel like you are apologizing to your groups of beginners, it would be wonderful if you could act as their advocate here. Obviously the issues directly affect you, so hopefully it is worth your time to engage us on this topic. And thank you for the messages you have sent. I know they have made me even more careful than I was already trying to be. -- R. David Murray www.bitdance.com [*] There may be a few exceptions to this where the 3.x library code fails to work in real-world applications, so that a more radical change is made but is, in reality, a bug fix. But even there we try to be conservative. ___ 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] Distutils2 scripts
On Fri, Oct 8, 2010 at 9:22 AM, Tarek Ziadé wrote: > pkg_manager ? 1. Underscores are evil. Don't do that. 2. Mixed shortened + written-out names are just nasty. > Mmm.. setup.py is gone in D2, and setup.py will be the marker of d1. Did we finally decide it could be done without setup.py entirely, in all cases? I guess I've been busy elsewhere lately. > Some project might want to provide both setups for backward > compatibility: > > - a setup.py (d1) > - a setup,cfg (d2 and optionally some d1 options) If a project requites setup.py for any reason, it can include the compatibility it needs there, even if there is sometimes a need for d2 to use a setup.py: try: import distutils2 except ImportError: import distutils.core distutils.core.setup(...) else: distutils2.core.setup() Anyway, the pysetup name offered in tis thread works for me as well. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Build failure in test_cmd_line on OSX-x86
I'm sure this has to be my configuration somehow, but I'm getting a build failure that I don't quite know how to debug, because I can't reproduce it when I run the test manually. Any advice would be appreciated-- I'm a buildslave newbie :-) I'm referring to http://www.python.org/dev/buildbot/builders/x86%20Snow%20Leopard%203.x/builds/13/steps/test/logs/stdio Now, when I saw this the first thing I assumed I should do is to try to reproduce it, so I did: Top-2:~ pythonbuildbot$ cp -R buildarea/3.x.hansen-osx-x86/ ~/test Top-2:~ pythonbuildbot$ cd ~/test/build/ Top-2:build pythonbuildbot$ ./configure --with-pydebug --with-computed-gotos [snip] Top-2:build pythonbuildbot$ make all [snip] I made sure to go check out the stdio for configure/compile so the compiling I'd do would be with the same options as the buildslave did. Then: Top-2:build pythonbuildbot$ ./python.exe -m test.regrtest -uall test_cmd_line.py [1/1] test_cmd_line 1 test OK. [84022 refs] Doh. So, next I try running the whole test suite: Top-2:build pythonbuildbot$ ./python.exe -m test.regrtest -uall [snip] [ 44/348] test_cmd_line And it passes too: but I notice its run way earlier in the test process then it did on the buildbot, and I remember reading awhile ago about a test failure that happened only when a certain test ran in a certain order. So, I go garb the randseed from the buildbot run and use it: Top-2:build pythonbuildbot$ ./python.exe -m test.regrtest -uall -r --randseed=9634655 == CPython 3.2a2+ (py3k:85321, Oct 8 2010, 08:54:05) [GCC 4.2.1 (Apple Inc. build 5664)] == Darwin-10.4.0-i386-64bit little-endian == /Users/pythonbuildbot/test/build/build/test_python_86644 Using random seed 9634655 [snip] And long story short, it gets to 201 and runs test_cmd_line in the same order as the buildbot did, and it succeeds too, and I curse the gods of the netherworld, and am stumped with how to proceed. Two separate buildbot runs and this same failure happened, yet for me, no. Or I'm doing something differently then the buildbot is, and I can't see what. --Stephen ___ 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] Distutils2 scripts
On Fri, Oct 8, 2010 at 7:01 PM, Fred Drake wrote: > On Fri, Oct 8, 2010 at 9:22 AM, Tarek Ziadé wrote: >> pkg_manager ? > > 1. Underscores are evil. Don't do that. > > 2. Mixed shortened + written-out names are just nasty. > >> Mmm.. setup.py is gone in D2, and setup.py will be the marker of d1. > > Did we finally decide it could be done without setup.py entirely, in > all cases? I guess I've been busy elsewhere lately. You mean like, having a distutils1 project without setup.py ? > >> Some project might want to provide both setups for backward >> compatibility: >> >> - a setup.py (d1) >> - a setup,cfg (d2 and optionally some d1 options) > > If a project requites setup.py for any reason, it can include the > compatibility it needs there, even if there is sometimes a need for d2 > to use a setup.py: > > > try: > import distutils2 > except ImportError: > import distutils.core > distutils.core.setup(...) > else: > distutils2.core.setup() At the last sprint, we ended up thinking that it would be better to have a setup.py that work only with distutils, and let people using setup.cfg for d2 (and if needed, hooks) This is way simpler for people because we can tell them: leave your setup.py as it is so you are compatible with installers like pip and easy_install for the time being, and add stuff in your .cfg. That way, they don't have to throw distutils2 code in the mix in setup.py, and be confused with all the subtle differences. And they'll follow that way the "no-setup.py" philosophy 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] Patch making the current email package (mostly) support bytes
On Sat, 09 Oct 2010 01:06:29 +0900, "Stephen J. Turnbull" wrote: > That mess is entirely unnecessary in Python 3. Text and wire format > can be easily distinguished with three different representations of > email: Unicode for the conceptual RFC 822 layer (of course this is an > extension, because RFC 822 itself is strictly limited to the ASCII > subset), bytes for wire format, and Message objects for modern > structured mail (including MIME, etc). > > *If* email6 is reengineered with that kind of structure, then you > should be able to dispense with almost all of the raft of defense, > because the email module will give you well-behaved Message objects, > whose text components (including the header) are well-behaved > character strings that mix seamlessly with other character strings. That engineering is pretty much what we are looking at, although in practice I think you have to hang wire-format and text-format bits off of appropriate places in the model in order to keep everything properly coordinated. > Maybe even in email5 I suspect that's pushing it. Patches happily accepted, though :) -- R. David Murray 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] Build failure in test_cmd_line on OSX-x86
On Fri, 8 Oct 2010 10:02:59 -0700 Stephen Hansen wrote: > > And long story short, it gets to 201 and runs test_cmd_line in the same > order as the buildbot did, and it succeeds too, and I curse the gods of the > netherworld, and am stumped with how to proceed. Two separate buildbot runs > and this same failure happened, yet for me, no. Or I'm doing something > differently then the buildbot is, and I can't see what. The buildbot user probably has different locale settings. I can simulate the failure with: $ PYTHONFSENCODING=latin1 ./python -m test.regrtest test_cmd_line [1/1] test_cmd_line test test_cmd_line failed -- Traceback (most recent call last): File "/home/antoine/py3k/__svn__/Lib/test/test_cmd_line.py", line 127, in test_run_code 0) AssertionError: 1 != 0 You should therefore see what the locale settings of the buildbot are (the LANG and LC_* environment variables). Of course, the test is also buggy so you should open an issue on the tracker. (and the fact that the test doesn't print the actual error message of the spawned interpreter is unhelpful) 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] Patch making the current email package (mostly) support bytes
On Fri, 08 Oct 2010 15:44:45 -, l...@rmi.net wrote: > Thanks for both your reply and work, David. I'm going to have > to test my email clients under the 3.2 patch when it gels. It's > good to hear that email5 API support remains a goal. I just landed the patch (though without the MIME encoding of unknown header bytes or the 'yes-I-really-want-the-escaped-bytes' flags that Stephen and I have been discussing. So it will be present in alpha3. I would greatly appreciate your testing it and making sure it doesn't break any of your code. > I don't mean to single out this change unfairly, of course. My > real concern is not as much with the specific technical aspects > of this proposal, as with the generally low priority that backward > compatibility sometimes receives on this list. The bytecode file I don't perceive that lack of priority myself. Certainly I don't see a lack of priority on backward compatibility in the bug tracker, quite the reverse[*]. As I said in my public email, specific examples would be most helpful. > model change in 3.2 comes to mind as another example; sound as it > may be, I'm not sure this list has any idea how many users, systems, > or docs may be impacted by this. Though not always true, the work > here does sometimes appear to be conducted in a vacuum. Well, we can only react to the input we find out about. Developers *do* read blogs and such about what's going on in the wider community and bring that info back to python-dev, but as is inherent with projects structured as volunteer efforts, what we get is only what someone decides to put in time on. Specific suggestions on how to improve the feedback loop are always welcome; volunteer efforts to improve our fundamental procedures are just as or perhaps more valuable than volunteer code writing (though they probably involve even more politicing effort :). > Ultimately, development in the open source world is driven by the > very few with time to show up, rather than by the very many who > depend on it. This can unfortunately lead to the perception > of thrashing by end users. Some even come to see the net effect > as not that much different from closed models. I have no solution Well, the Python community takes it as a principle to avoid thrashing. So if you see examples where we are failing in that goal, call us on it (with specifics). > to offer, except to underscore again that changes made here affect > very many people who are too busy using Python to participate here. > Especially given the still tentative state of 3.X, stability matters. We do try to remain aware of that. When we fail, someone needs to let us know. -- R. David Murray www.bitdance.com [*] I'm currently aware of one exception to this, the nttplib module. It was pretty much unusable as it stood (I tried, as did Antoine; it had no unit tests so massive breakage is not that surprising), so we broke backward compatibility with 3.1 in order to fix that. ___ 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] Patch making the current email package (mostly) support bytes
On Fri, 08 Oct 2010 23:55:37 +0900, "Stephen J. Turnbull" wrote: > I should think you *want* addresses and suchlike structured headers > (Content-Type with several RFC 2231 parameters, anyone?) to line up > nicely, too. So generic folding algorithms are really only applicable > to unstructured text fields like Subject and Summary anyway. > > You can call that "sucky" if you like, I prefer to call it "tasteful." No, what's sucky is that email4/5 doesn't support that. It only folds headers as unstructured blobs, with a nod in the direction of structure by breaking lines at "obvious" places like ';'s. (Which line breaking algorithm is the subject of at least one bug report) I'd like to fix that in email6 by adding full support for structured headers. -- R. David Murray 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] Patch making the current email package (mostly) support bytes
On Fri, 08 Oct 2010 12:37:38 +0900, "Stephen J. Turnbull" wrote: > *If* you have an 8-bit value of unknown encoding on input, this will > appear in the Header's value as a surrogate. Hm, OK, I see the > problem ... as usual, it's that the only efficient thing to do is > encode using surrogate-escape which loses the information that these > are invalid bytes. Would it really be that bad to add an O(length) > component where you examine the string for surrogates (and too-long > words, for that matter), and chop off those pieces for MIME encoding? Nope, and that's more or less what I think I'm going to do. But I haven't started writing the code yet. > > > > Presumably you are suggesting that email5 be smart enough to turn my > > > > example into properly UTF-8/CTE encoded text. > > > > > > No, in general that's undecidable without asking the originator, > > > although humans can often make a good guess. > > > > I was talking about unicode input, though, where you do know (modulo > > the language differences that unicode hasn't yet sorted out). > > I don't understand why this is difficult. As far as what Unicode has It isn't difficult in principle. It's just difficult in email5. -- R. David Murray 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] Distutils2 scripts
On 10/8/10 10:26 AM, Barry Warsaw wrote: No underscores, please. :) Indeed! In any case, these could be a simple shell script wrapping 'python -m setup'. It could even take a --use-python-version option to select the pythonX.Y it used, without having to encode the Python version number in the script name. On Windows it can't be a shell script or batch file, but needs to be an executable. setuptools already deals with this. -- Eric. ___ 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] Patch making the current email package (mostly) support bytes
R. David Murray writes: > On Sat, 09 Oct 2010 01:06:29 +0900, "Stephen J. Turnbull" > wrote: > > That mess is entirely unnecessary in Python 3. Text and wire format > > can be easily distinguished with three different representations of > > email: Unicode for the conceptual RFC 822 layer (of course this is an > > extension, because RFC 822 itself is strictly limited to the ASCII > > subset), bytes for wire format, and Message objects for modern > > structured mail (including MIME, etc). > That engineering is pretty much what we are looking at, although in > practice I think you have to hang wire-format and text-format bits off > of appropriate places in the model in order to keep everything properly > coordinated. Right. That's where I was going with my comment to Barry about the Received headers. Even if email isn't going to serve clients working with wire format, it needs to deal with those headers. But where I think the headers defined by RFC 822 should be stored as str in email6, I am leaning toward storing Received headers verbatim as bytes (including any RFC 822 folding whitespace) because of the RFC 5321 requirement that they be preserved exactly. ___ 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] Build failure in test_cmd_line on OSX-x86
On Fri, Oct 8, 2010 at 10:28 AM, Antoine Pitrou wrote: > On Fri, 8 Oct 2010 10:02:59 -0700 > Stephen Hansen > wrote: > > > > And long story short, it gets to 201 and runs test_cmd_line in the same > > order as the buildbot did, and it succeeds too, and I curse the gods of > the > > netherworld, and am stumped with how to proceed. Two separate buildbot > runs > > and this same failure happened, yet for me, no. Or I'm doing something > > differently then the buildbot is, and I can't see what. > > The buildbot user probably has different locale settings. I can > simulate the failure with: > I'd find that very surprising: the buildslave is running as the same user I am running the test under, and the LANG is en_US.UTF-8 -- the default. Granted, the slave's running under launchd, and so is launching twisted with the tac directly -- but I can't see any part of that process which would cause the default LANG to change. Interestingly enough, I can't reproduce the failure with: Top-2:build pythonbuildbot$ PYTHONFSENCODING=latin1 ./python.exe -m test.regrtest -uall test_cmd_line.py [1/1] test_cmd_line 1 test OK. [84024 refs] (and just to test--) Top-2:build pythonbuildbot$ PYTHONFSENCODING="utf-8" ./python.exe -m test.regrtest -uall test_cmd_line.py [1/1] test_cmd_line 1 test OK. [84024 refs] But I don't think that environment variable does anything on the Mac; I'm pretty sure the fs encoding is set as utf-8 and mandated as such in the OS. > You should therefore see what the locale settings of the buildbot are > (the LANG and LC_* environment variables). Of course, the test is also > buggy so you should open an issue on the tracker. > I'm just not sure what to say about it or in what way its being buggy yet, so can't open an issue :) > (and the fact that the test doesn't print the actual error message of > the spawned interpreter is unhelpful) > Agreed. --S ___ 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] Patch making the current email package (mostly) support bytes
On Oct 08, 2010, at 03:44 PM, l...@rmi.net wrote: >Ultimately, development in the open source world is driven by the >very few with time to show up, rather than by the very many who >depend on it. This can unfortunately lead to the perception >of thrashing by end users. Some even come to see the net effect >as not that much different from closed models. I have no solution >to offer, except to underscore again that changes made here affect >very many people who are too busy using Python to participate here. >Especially given the still tentative state of 3.X, stability matters. I'm reminded of a survey Guido conducted at some long past Python conference. He asked (paraphrasing): raise your hand if you think Python is changing too fast. Lots of hands went up. Then he asked, raise your hand if you have a feature you want to get in the next version. Lots of hands went up. I'm sympathetic to the view that changes in Python can be disruptive to end users. The Python community itself takes this seriously too, as evidenced by the language moratorium[*]. But OTOH, Python cannot stagnate and even fixing things means changing things. The reality too is that Python releases come out approximately every 18 months, and a year and a half can either seem like an excruciatingly long time, or blink of the eye depending on which side of the fence you stand on. Yes, stability matters, but Python 3 is still a new snakeling and I suspect that as the pace of porting picks up, more changes will be necessary. Adding new modules named like distutils2 or unittest2 is less than satisfying but useful for keeping older APIs around. I'm sad to hear that some people think that our development model differs little from closed source development. To me, nothing could be further from the truth. But the adage does go "(s)he who does the work, decides", and this is the forum for those who are doing the work. I think everyone here welcomes advocates for under-represented Python communities, and their concerns should be taken in consideration when changes are discussed. But ultimately, Python must evolve to stay relevant or it will die. This is where competing design trade-offs must be discussed. If not here, by us, then where and by whom? -Barry [*] Mostly instituted to allow alternative implementations to catch up, it does necessarily slow the pace of changes visible to end users. signature.asc Description: 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] Patch making the current email package (mostly) support bytes
On Oct 09, 2010, at 02:48 AM, Stephen J. Turnbull wrote: >Right. That's where I was going with my comment to Barry about the >Received headers. Even if email isn't going to serve clients working >with wire format, it needs to deal with those headers. But where I >think the headers defined by RFC 822 should be stored as str in >email6, I am leaning toward storing Received headers verbatim as bytes >(including any RFC 822 folding whitespace) because of the RFC 5321 >requirement that they be preserved exactly. I think then you'd have to have two different APIs. It'll just be too confusing and error prone to return either bytes or strs from header value accessors depending on the header name. -Barry signature.asc Description: 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] Distutils2 scripts
On Fri, Oct 8, 2010 at 4:49 PM, Eric Smith wrote: ... > > On Windows it can't be a shell script or batch file, but needs to be an > executable. setuptools already deals with this. Why ? The script-wrapping feature Setuptools has is on my radar for d2, but I am not sure why it's an advantage in that case. Tarek -- Tarek Ziadé | http://ziade.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
Re: [Python-Dev] Distutils2 scripts
On 10/8/10 2:41 PM, Tarek Ziadé wrote: On Fri, Oct 8, 2010 at 4:49 PM, Eric Smith wrote: ... On Windows it can't be a shell script or batch file, but needs to be an executable. setuptools already deals with this. Why ? The script-wrapping feature Setuptools has is on my radar for d2, but I am not sure why it's an advantage in that case. It can't be a batch file because then it can't be called from other batch files (without using the "call" syntax). I guess there are other options like using WSH (or newer technology), but then you have to pick your target OS carefully. I think the setuptools approach is the preferred solution, although of course it's a hassle. -- Eric. ___ 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] Build failure in test_cmd_line on OSX-x86
On Fri, Oct 8, 2010 at 11:09 AM, Stephen Hansen > wrote: > On Fri, Oct 8, 2010 at 10:28 AM, Antoine Pitrou wrote: > >> On Fri, 8 Oct 2010 10:02:59 -0700 >> Stephen Hansen > wrote: >> > >> > And long story short, it gets to 201 and runs test_cmd_line in the same >> > order as the buildbot did, and it succeeds too, and I curse the gods of >> the >> > netherworld, and am stumped with how to proceed. Two separate buildbot >> runs >> > and this same failure happened, yet for me, no. Or I'm doing something >> > differently then the buildbot is, and I can't see what. >> >> The buildbot user probably has different locale settings. I can >> simulate the failure with: >> > > I'd find that very surprising: the buildslave is running as the same user I > am running the test under, and the LANG is en_US.UTF-8 -- the default. > Granted, the slave's running under launchd, and so is launching twisted with > the tac directly -- but I can't see any part of that process which would > cause the default LANG to change. > I edited the launchd config to force LANG = "en_US.UTF-8" and the test suddenly passes, which is good. I have no idea why the LANG would end up different when the app is launched from launchd -- even though it was running as the same user as I was doing the testing against -- but, apparently, it was. But, issue4388 and issue9992 seem to already be in, and I commented on them. Thanks for the help in figuring this out. :) --Stephen/Ixokai ___ 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] Distutils2 scripts
On Fri, Oct 8, 2010 at 09:25, Tarek Ziadé wrote: > On Fri, Oct 8, 2010 at 5:53 PM, Toshio Kuratomi wrote: >> On Fri, Oct 08, 2010 at 05:12:44PM +0200, Antoine Pitrou wrote: > ... >>> > pysetup is shorter > > Let's use pysetup ! > > ... >> I won't bikeshed as long as we stay away from conflicting names. > > +1. > > So. Let's add pysetup in distutils2, that will be installed as a > classical script. Once we move distutils2 back in the stdlib, it will > be provided in Python's bin dir, so people will have the same > "pysetup" name everywhere, I am not about to bikeshed on the name, but I would like to publicly shed a single tear for no one even suggesting a Monty Python name closer than "quiche". I think going with PyPI over Cheeseshop helped put an end to that naming scheme, and that's a shame. Anyway, I can always alias pysetup to cheeseshop or ohmightytim on my machine and reminisce. ___ 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] Patch making the current email package (mostly) support bytes
On Sat, 09 Oct 2010 02:48:23 +0900, "Stephen J. Turnbull" wrote: > R. David Murray writes: > > On Sat, 09 Oct 2010 01:06:29 +0900, "Stephen J. Turnbull" > wrote: > > > That mess is entirely unnecessary in Python 3. Text and wire format > > > can be easily distinguished with three different representations of > > > email: Unicode for the conceptual RFC 822 layer (of course this is an > > > extension, because RFC 822 itself is strictly limited to the ASCII > > > subset), bytes for wire format, and Message objects for modern > > > structured mail (including MIME, etc). > > > That engineering is pretty much what we are looking at, although in > > practice I think you have to hang wire-format and text-format bits off > > of appropriate places in the model in order to keep everything properly > > coordinated. > > Right. That's where I was going with my comment to Barry about the > Received headers. Even if email isn't going to serve clients working > with wire format, it needs to deal with those headers. But where I > think the headers defined by RFC 822 should be stored as str in > email6, I am leaning toward storing Received headers verbatim as bytes > (including any RFC 822 folding whitespace) because of the RFC 5321 > requirement that they be preserved exactly. Well, the plan for email6 is to *allow* clients to work with wire format, though it will probably be a bit more awkward than working with the text interface. And my current strategy is in general to preserve the input bytes and, as long as the header in question hasn't been modified, emit those bytes when serialization back to bytes is done. My current plan is that conversion to text is only done at the point where text is requested, at which point the conversion is cached for later use. And if the header is modified, the source bytes version is discarded. Conversely if the source of the header was text input (msg['Subject'] = 'Hi'), then the conversion to bytes is only done when serialization to bytes is requested. None of this is implemented yet. -- R. David Murray 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] Patch making the current email package (mostly) support bytes
Barry Warsaw writes: > On Oct 09, 2010, at 02:48 AM, Stephen J. Turnbull wrote: > > >Right. That's where I was going with my comment to Barry about the > >Received headers. Even if email isn't going to serve clients working > >with wire format, it needs to deal with those headers. But where I > >think the headers defined by RFC 822 should be stored as str in > >email6, I am leaning toward storing Received headers verbatim as bytes > >(including any RFC 822 folding whitespace) because of the RFC 5321 > >requirement that they be preserved exactly. > > I think then you'd have to have two different APIs. It'll just be too > confusing and error prone to return either bytes or strs from header value > accessors depending on the header name. Ah, but you wouldn't *return* those bytes with the value accessor, you'd return str, because that's what clients expect. And you wouldn't store bytes with a mutator -- or store a str for that matter: you get an error because the value is immutable. You would initialize it with a special initializer accepting the RFC 5321 components (and those arguments would be str and DateTimes and stuff like that). IOW, the implementation would share basically nothing with ordinary Headers, but the API would seem familiar, up to specific semantics like immutability. (And you also wouldn't be able to delete it with the usual interface; there would be a special API meaning "I really do want to delete this Received header, and I do understand that deletion is prohibited where RFC 5321 rules.") The choice of storage medium is purely an optimization (and to remind you that this header is actually part of the wire protocol). It's probably more trouble than it's worth. ___ 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] Distutils2 scripts
On Fri, 08 Oct 2010 12:31:07 -0700, Brett Cannon wrote: > I am not about to bikeshed on the name, but I would like to publicly > shed a single tear for no one even suggesting a Monty Python name > closer than "quiche". I think going with PyPI over Cheeseshop helped > put an end to that naming scheme, and that's a shame. > > Anyway, I can always alias pysetup to cheeseshop or ohmightytim on my > machine and reminisce. Or thebookofarmaments. -- R. David Murray 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] Distutils2 scripts
On Oct 8, 2010, at 9:22 , Jeroen Ruigrok van der Werven wrote: > +1 from me. I sincerely dislike the Perl-esque -m stuff. As a Perl/Python guy I have to object to calling the -m stuff Perl-esque. This is a very Pythonish thing. In the Perl world we never treat modules as scripts; they are separate concepts written separately and installed in separate locations. There is no feature of perl similar to the Pythonish -m stuff. Regards, Gisle ___ 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] Build failure in test_cmd_line on OSX-x86
In article , Stephen Hansen wrote: > I edited the launchd config to force LANG = "en_US.UTF-8" and the test > suddenly passes, which is good. I have no idea why the LANG would end up > different when the app is launched from launchd -- even though it was > running as the same user as I was doing the testing against -- but, > apparently, it was. OS X does not automatically set LANG in all "launch" environments. Terminal.app in 10.5 and 10.6 has a preference to "set locale environment variables on startup" so, if you are running under it, you'll see LANG set. But if you execute via launchd or ssh (for instance), it will not automatically be set unless you do something like explicitly set and export it in a shell startup file. -- Ned Deily, n...@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
Re: [Python-Dev] Distutils2 scripts
On Fri, Oct 8, 2010 at 9:31 PM, Brett Cannon wrote: > On Fri, Oct 8, 2010 at 09:25, Tarek Ziadé wrote: >> On Fri, Oct 8, 2010 at 5:53 PM, Toshio Kuratomi wrote: >>> On Fri, Oct 08, 2010 at 05:12:44PM +0200, Antoine Pitrou wrote: >> ... > pysetup is shorter >> >> Let's use pysetup ! >> >> ... >>> I won't bikeshed as long as we stay away from conflicting names. >> >> +1. >> >> So. Let's add pysetup in distutils2, that will be installed as a >> classical script. Once we move distutils2 back in the stdlib, it will >> be provided in Python's bin dir, so people will have the same >> "pysetup" name everywhere, > > I am not about to bikeshed on the name, but I would like to publicly > shed a single tear for no one even suggesting a Monty Python name > closer than "quiche". I think going with PyPI over Cheeseshop helped > put an end to that naming scheme, and that's a shame. > > Anyway, I can always alias pysetup to cheeseshop or ohmightytim on my > machine and reminisce. Hehe. What's the story behind changing the name from Cheeseshop to PyPI btw ? I found the first one much nicer > -- Tarek Ziadé | http://ziade.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
Re: [Python-Dev] python.org going down?
Am 08.10.2010 09:21, schrieb Jeroen Ruigrok van der Werven: > -On [20101008 01:22], "Martin v. Löwis" (mar...@v.loewis.de) wrote: >> True. However, I really cannot see anything on the machines that >> indicates some outage. I'm still unsure what "it" is that was happening, >> so it's also difficult to analyse this further. > > It's hosted by XS4All, they had some network problems yesterday at least. I > am not sure if it would explain this behaviour, might be one of the uplinks > or peers had some issues. Ah. That would explain it, indeed. Regards, Martin ___ 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] Distutils2 scripts
On Fri, Oct 8, 2010 at 14:44, Tarek Ziadé wrote: > On Fri, Oct 8, 2010 at 9:31 PM, Brett Cannon wrote: >> On Fri, Oct 8, 2010 at 09:25, Tarek Ziadé wrote: >>> On Fri, Oct 8, 2010 at 5:53 PM, Toshio Kuratomi wrote: On Fri, Oct 08, 2010 at 05:12:44PM +0200, Antoine Pitrou wrote: >>> ... > > pysetup is shorter >>> >>> Let's use pysetup ! >>> >>> ... I won't bikeshed as long as we stay away from conflicting names. >>> >>> +1. >>> >>> So. Let's add pysetup in distutils2, that will be installed as a >>> classical script. Once we move distutils2 back in the stdlib, it will >>> be provided in Python's bin dir, so people will have the same >>> "pysetup" name everywhere, >> >> I am not about to bikeshed on the name, but I would like to publicly >> shed a single tear for no one even suggesting a Monty Python name >> closer than "quiche". I think going with PyPI over Cheeseshop helped >> put an end to that naming scheme, and that's a shame. >> >> Anyway, I can always alias pysetup to cheeseshop or ohmightytim on my >> machine and reminisce. > > Hehe. What's the story behind changing the name from Cheeseshop to PyPI btw ? > I found the first one much nicer Richard Jones is the authority on the story, but from what I can remember from the discussion it was decided that managers would have had issues with using a service called the Cheeseshop. So basically the idea of professional-sounding name won out. I still use cheeseshop.python.org to access the package index. ___ 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] Distutils2 scripts
On Oct 8, 2010, at 5:24 PM, Gisle Aas wrote: > On Oct 8, 2010, at 9:22 , Jeroen Ruigrok van der Werven wrote: > >> +1 from me. I sincerely dislike the Perl-esque -m stuff. > > As a Perl/Python guy I have to object to calling the -m stuff Perl-esque. > This is a very Pythonish thing. In the Perl world we never treat modules as > scripts; they are separate concepts written separately and installed in > separate locations. There is no feature of perl similar to the Pythonish -m > stuff. Yes there is. -m and -M. E.g., the widely advertised perl -MCPAN -e install. It's not identical to python's -m, to be sure, but it's *similar*. James ___ 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] Another relative imports question
Georg Brandl wrote: The explanation is that everything that comes after "import" is thereafter usable as an identifier (or expression, in the case of dotted names) in code. ".mymodule" is not a valid expression, so the question would be how to refer to it. I think a reasonable answer is that you should be able to refer to it simply as 'mymodule'. This may require treating it as a bit of a special case, but it would make intuitive sense. -- 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
