Re: [Python-Dev] os.path.normcase rationale?
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? 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 ;-) I still don't really get the use case of normpath in its current form, at all... Various people have posted links to recipes that solve case #2. Note though that this necessarily demands that if the file doesn't exist, it should raise an exception. Fine by me, shame it seems to require iteration to find an answer though :-S The very concept of canonical form for file names is troublesome. I would have thought "whatever is shown when doing an ls/dir/etc" (and don't be smart and think about mentioning that oyu can get dir to output 8.3 as well as the full path ;-) ) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.normcase rationale?
On 25/09/2010 15:45, Guido van Rossum wrote: The solution may well be OS specific. Solutions for Windows and OS X have already been pointed out. If it can't be done for other Unix versions, I think returning the input unchanged on those platform is a fine fallback (as it is for non-existent filenames). Spot on, especially as the "default" of case perserving and case sensitive will likely cover anything where an FS-specific solution can't be found - I'd hazard a guess that the reason the FS-sepcific solution can't be found in some cases is because for case preserving and case sensitive situations, there really is no need for such an api ;-) Chris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] issue 9807 - a glitch in coexisting builds of different types
-On [20101004 22:03], Barry Warsaw ([email protected]) wrote: >We already have libpython3.2.so.1.0 which also doesn't end in .so. I suppose >we could put the build flags before the .so. part, but I think Matthias had a >problem with that (I don't remember the details). Using major and minor numbers after the .so designation is an old aout (de facto) standard. ELF settled on just major numbers. And typically you will find a symbolic link from libwhatever.so to libwhatever.so.1 Also, from FreeBSD's ldconfig manual page: "Filenames must conform to the lib*.so.[0-9] pattern in order to be added to the hints file." So ending a shared object with the build flags will cause problems on FreeBSD and probably the other BSDs (DragonFly, NetBSD, OpenBSD) and most likely Mac OS X as well. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Time is merely a residue of Reality... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] issue 9807 - a glitch in coexisting builds of different types
-On [20101004 20:48], Barry Warsaw ([email protected]) wrote: >On Oct 02, 2010, at 01:40 PM, Antoine Pitrou wrote: > >>Besides, mingling different installations together makes uninstalling >>much more difficult. > >Not for a distro I think. It does. On BSD the ports and packages are referred to a specific location in the ports tree, e.g. ports/lang/python26, so any Python 2.6 compiled and installed from ports with specific options will *always* point to this location. So if you want to install 2 versions of Python 2.6 with different options, you are out of luck using the standard way. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Looking for the Sun that eclipsed behind black feathered wings... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.normcase rationale?
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. Some file systems are case-preserving, and don't have a canonical form. We might choose to arbitrarily impose one, as normcase already does. Some are case-folding, in which case it might be sensible to choose the same canonical form as the file system actually uses. However, this may be implementation dependent e.g. under FAT12 or FAT16, the file system will take a file name like pArRoT.tXt and fold it to PARROT.TXT, or possibly parrot.txt, or Parrot.txt. Even if that's not the case for FAT12, it may be the case for other case-folding file systems. And the behaviour of FAT16 will differ according to whether or not it has been built with support for long file names. 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.) For simplicity, suppose you're on Windows using NTFS with the standard non-POSIX behaviour. You create a file named pArRoT.tXt. This will be stored on disk using the exact characters that you typed. The file system does no case-folding and merely uses whatever characters are fed to it, which in the case of Windows apps is likely to be whatever characters the user types. In this case, we don't try to impose a particular case on file names, but return whatever actually exists on disk. > 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. 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. 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 :) -- Steven D'Aprano ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding Wing 4 project to
Hello all, There is a Wing IDE [1] project file in Misc/ which I use for working on Python. The project file is 'python-wing.wpr'. Wing 4 is now in beta and I have switched to using it. Wing 4 uses an updated, backwards incompatible, project file format. I would like to add a Wing 4 project file to Misc, called 'python-wing4.wpr' to all the branches I work on (likely py3k, python27-maint and python31-maint). Any objections to this? Once Wing 4 is out of beta there are several options. Major version updates to Wing are infrequent, so the options are listed in my order of preference: 1. rename the old file 'python-wing3.wpr' and rename 'python-wing4.wpr' to 'python-wing.wpr' 2. delete the wing 3 project file altogether and rename 'python-wing4.wpr' to 'python-wing.wpr' 3. stay with versioned project file names and rename 'python-wing.wpr' to 'python-wing3.wpr' (Option 3 could be done immediately of course.) All the best, Michael Foord [1] http://wingware.com/ -- http://www.voidspace.org.uk/blog 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding Wing 4 project to
On Tue, Oct 05, 2010 at 12:39:00PM +0100, Michael Foord wrote: > Wing 4 is now in beta and I have switched to using it. Wing 4 uses > an updated, backwards incompatible, project file format. I would > like to add a Wing 4 project file to Misc, called 'python-wing4.wpr' > to all the branches I work on (likely py3k, python27-maint and > python31-maint). > > Any objections to this? One of the concerns would be size. How much does the new extra file add to the tarball (and to Windows/Mac builds, if they are bundling). -- Senthil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding Wing 4 project to
On 05/10/2010 12:51, Senthil Kumaran wrote:
On Tue, Oct 05, 2010 at 12:39:00PM +0100, Michael Foord wrote:
Wing 4 is now in beta and I have switched to using it. Wing 4 uses
an updated, backwards incompatible, project file format. I would
like to add a Wing 4 project file to Misc, called 'python-wing4.wpr'
to all the branches I work on (likely py3k, python27-maint and
python31-maint).
Any objections to this?
One of the concerns would be size. How much does the new extra file
add to the tarball (and to Windows/Mac builds, if they are bundling).
>>> len(open('Misc/python-wing.wpr').read())
555
>>> len(open('Misc/python-wing4.wpr').read())
888
Michael
--
http://www.voidspace.org.uk/blog
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding Wing 4 project to
On Tue, Oct 5, 2010 at 5:25 PM, Michael Foord wrote:
len(open('Misc/python-wing.wpr').read())
> 555
len(open('Misc/python-wing4.wpr').read())
> 888
So, "size doesn't matter". :)
--
Senthil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding Wing 4 project to
On Tue, 05 Oct 2010 12:39:00 +0100 Michael Foord wrote: > > 1. rename the old file 'python-wing3.wpr' and rename 'python-wing4.wpr' > to 'python-wing.wpr' > 2. delete the wing 3 project file altogether and rename > 'python-wing4.wpr' to 'python-wing.wpr' > 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. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch making the current email package (mostly) support bytes
On Tue, Oct 5, 2010 at 3:41 PM, Stephen J. Turnbull wrote: > R. David Murray writes: > > Only if the email package contains a coding error would the > > surrogates escape and cause problems for user code. > > I don't think it is reasonable to internalize surrogates that way; > some applications *will* want to look at them and do something useful > with them (delete them or replace them with U+FFFD or ...). However, > I argue below that the presence of surrogates already means the user > code is under fire, and this puts the problem in a canonical form so > the user code can prepare for it (if that is desirable). Hang on here, this objection doesn't seem to quite mesh with what RDM is proposing (and the similar trick I am considering for urllib.parse). The basic issue is having an algorithm that is designed to operate on character data and depends on multiple ASCII constants stored as str objects. In Python 2.x, those algorithms could innately operate on str objects in any ASCII compatible encoding, as well as on unicode objects (due to the implicit promotion of the ASCII constants to unicode when unicode input was encountered). In Py3k, that trick broke. Now those algorithms only operate on str objects, and bytes input fails, even when it uses an ASCII compatible encoding. For urllib.parse, the external API will be "str in -> str out, bytes in -> bytes out". Whether that is internally implemented by duplicating all the ASCII constants with both bytes and str flavours (as my current patch does), or implicitly (and temporarily) "decoding" the bytes values using ascii+surrogateescape or latin-1 (a pair of alternative approaches I plan to explore soon) should be completely transparent to the user of the API. If a user can easily tell which of these I am doing just through the external behaviour of the documented API, then I'll have made a mistake somewhere. My understanding is that email6 in 3.3 will essentially follow that same model. What I believe RDM is suggesting is an in-between approach for the 3.2 email module: - if you pass in bytes data that isn't 7-bit clean and naively use the str APIs to access the headers, then it will complain loudly if it is about to return escaped data (but will decode the body in accordance with the Content Transfer Encoding) - if you pass in bytes data and know what you are doing, then you can access that raw bytes data and do your own decoding I've probably grossly oversimplified what RDM is suggesting, but it sounds plausible as a useful interim stepping stone to the more comprehensive type separation in email6. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Who wants to donate an AMD64 Linux build slave?
We just lost Neal's AMD-64 build slave due to hardware problems. There is another AMD6-64 slave in the pool, however, it runs in a non-standard environment, so it shows test failures at the moment. Would anybody be willing to run a build slave on a machine that you have available? The main requirement is that the machine is always connected to the internet, although not necessarily with a fixed IP address. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who wants to donate an AMD64 Linux build slave?
On Tue, Oct 5, 2010 at 11:19, "Martin v. Löwis" wrote: > Would anybody be willing to run a build slave on a machine that > you have available? The main requirement is that the machine is > always connected to the internet, although not necessarily with > a fixed IP address. I can probably run a build slave on one of my boxes (Gentoo, Athlon 64 x2). Where are the setup docs? Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyCon 2011 Call for Tutorials
NB: Posting on behalf of Greg Lindstrom, our tutorial coordinator: PyCon 2011 will be held March 9th through the 17th, 2011 in Atlanta, Georgia. (Home of some of the best southern food you can possibly find on Earth!) The PyCon conference days will be March 11-13, preceded by two tutorial days (March 9-10), and followed by four days of development sprints (March 14-17). The call for tutorial proposals is open until November 1 and we want to encourage you to submit a class idea! Teachers are paid for their efforts and it's a great opportunity for you to teach to a room full of people who have paid to hear what you have to say? Tutorials are 3-hour long classes (with a refreshment break) taught be some of the leading minds in the Python community. Classes range from beginner (Introduction to Python) to advanced (OOP, Data Storage and Optimization) and everything in between. If you don't feel up to teaching a class, you can always encourage your favorite mentor to teach it! Anything Python may be proposed for a class and a variety of topics is always presented but we can't offer what isn't proposed! Get more information at http://us.pycon.org/2011/about/ under the "Tutorial Days" section. Submit your idea on the site under the "Speakers" tab. That's it! You could be teaching a class at PyCon next March. See you in Atlanta! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] issue 9807 - a glitch in coexisting builds of different types
On Oct 04, 2010, at 10:18 PM, Antoine Pitrou wrote: >What is the point of shipping a different unicode representation? Is >there any practical use case? I could understand a motivated user >trying different build flags for the purpose of experimentation and >personal enlightenment, but a Linux distribution? >(also, Debian's Python already defaults on wide unicode) True, it may not make sense to ship different unicode builds, but certainly it makes sense to ship debug and non-debug builds. But I don't think it makes sense to special case that when we already handle the build flags according to PEP 3149. Also, I do think there is a valid use case for developers here. I might indeed want to install into /usr/local various different builds of Python for testing purposes (e.g. user reported my extension module crashes when --without-unicode --with-pydebug is given). To me, we're mostly discussing user interface. What binary names to we want to present to the end user? Through the use of symlinks we can present any name we want. I don't personally think having additional build-flagged names hurts the user, but if there's strong disagreement, then I'm not opposed to exposing them optionally through a configure flag and/or new Makefile target. I just don't think it's necessary. >> >As for the SOABI, you could use a different mangling which would >> >preserve the ".so" suffix -- e.g. "-debug.so" instead of ".so.d". At >> >least then well-known conventions would be preserved. >> >> We already have libpython3.2.so.1.0 which also doesn't end in .so. > >".so." is a well-understood Unix convention, while >".so." doesn't seem to be. >(this also means that tools such as file managers etc. may not display >the file type properly) Okay. I'll try to modify the patch to put the build-flags before the .so when --enable-shared is given. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] issue 9807 - a glitch in coexisting builds of different types
On Oct 05, 2010, at 10:45 AM, Jeroen Ruigrok van der Werven wrote: >-On [20101004 20:48], Barry Warsaw ([email protected]) wrote: >>On Oct 02, 2010, at 01:40 PM, Antoine Pitrou wrote: >> >>>Besides, mingling different installations together makes uninstalling >>>much more difficult. >> >>Not for a distro I think. > >It does. On BSD the ports and packages are referred to a specific >location in the ports tree, e.g. ports/lang/python26, so any Python >2.6 compiled and installed from ports with specific options will >*always* point to this location. So if you want to install 2 versions >of Python 2.6 with different options, you are out of luck using the >standard way. Do any BSD distros provide multiple different builds of Python to their users? How do they handle having a debug build or non-debug build? -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] issue 9807 - a glitch in coexisting builds of different types
On Oct 05, 2010, at 10:50 AM, Jeroen Ruigrok van der Werven wrote: >Also, from FreeBSD's ldconfig manual page: > >"Filenames must conform to the lib*.so.[0-9] pattern in order to be >added to the hints file." > >So ending a shared object with the build flags will cause problems on >FreeBSD and probably the other BSDs (DragonFly, NetBSD, OpenBSD) and >most likely Mac OS X as well. Fair enough. I will change the patch to move the build flags when --enable-shared is used. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] question/comment about documentation of relative imports
I have a couple questions/comments about the use of PEP 328-style
relative imports. For example, the faq at
http://docs.python.org/py3k/faq/programming.html#what-are-the-best-practices-for-using-import-in-a-module
reads:
"Never use relative package imports. If you’re writing code that’s in
the package.sub.m1 module and want to import package.sub.m2, do not
just write from . import m2, even though it’s legal. Write from
package.sub import m2 instead. See PEP 328 for details."
There is no explanation to support the claim that relative imports
should "never" be used. It seems to me that someone read the following
in PEP 328::
from .moduleY import spam
from .moduleY import spam as ham
from . import moduleY
from ..subpackage1 import moduleY
from ..subpackage2.moduleZ import eggs
from ..moduleA import foo
from ...package import bar
from ...sys import path
Note that while that last case is legal, it is certainly
discouraged ("insane" was the word Guido used).
... and interpreted it to mean that relative imports are in general
discouraged. I interpreted it to mean that relative imports should not
be used to import from python's standard library.
There are cases where it is necessary to use relative imports, like a
package that is included as a subpackage of more than one other
project (when it is not acceptable to add an external dependency, for
example due to version/compatibility issues). There is some additional
context on relative imports in the programming faq for python-2.7 at
http://docs.python.org/faq/programming.html#what-are-the-best-practices-for-using-import-in-a-module
:
"Never use relative package imports. If you’re writing code that’s in
the package.sub.m1 module and want to import package.sub.m2, do not
just write import m2, even though it’s legal. Write from package.sub
import m2 instead. Relative imports can lead to a module being
initialized twice, leading to confusing bugs. See PEP 328 for
details."
Is there some documentation explaining why the module may be
initialized twice? I don't see it in PEP 328. Is this also the case
for python-3, or does it only apply to the old-style (pre-PEP 328)
relative imports in python-2? If relative imports are truly so
strongly discouraged, then perhaps warnings should also be included in
places like http://docs.python.org/library/functions.html#__import__ ,
and especially
http://docs.python.org/tutorial/modules.html#intra-package-references
and http://www.python.org/dev/peps/pep-0328/ (which, if I have
misinterpreted, is ambiguously written. Though I doubt this is the
case).
There is also this warning against relative imports in PEP 8:
- Relative imports for intra-package imports are highly discouraged.
Always use the absolute package path for all imports.
Even now that PEP 328 [7] is fully implemented in Python 2.5,
its style of explicit relative imports is actively discouraged;
absolute imports are more portable and usually more readable.
... but one could argue, as I just have, that relative imports are
more portable, not less. In a sense, the statement "explicit relative
imports is actively discouraged" is objectively false. They are
passively discouraged. If they were actively discouraged, perhaps
performing a relative import would raise a warning, or maybe distutils
would raise a warning at install time, or maybe an additional import
would be required to enable them. Up until now, I was not aware that
use of PEP 328 relative imports might be discouraged. I'm still
unclear as to why they might be discouraged. I recently helped convert
a popular package to use PEP 328 relative imports. Would the python
devs consider this a mistake?
Thanks,
Darren
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch making the current email package (mostly) support bytes
On Tue, 05 Oct 2010 22:05:33 +1000, Nick Coghlan wrote: > On Tue, Oct 5, 2010 at 3:41 PM, Stephen J. Turnbull > wrote: > > R. David Murray writes: > > > Only if the email package contains a coding error would the > > > surrogates escape and cause problems for user code. > > > > I don't think it is reasonable to internalize surrogates that way; > > some applications *will* want to look at them and do something useful > > with them (delete them or replace them with U+FFFD or ...). However, > > I argue below that the presence of surrogates already means the user > > code is under fire, and this puts the problem in a canonical form so > > the user code can prepare for it (if that is desirable). > > Hang on here, this objection doesn't seem to quite mesh with what RDM > is proposing (and the similar trick I am considering for > urllib.parse). [snip Nick's clear explanation of the issue and using surrogates to allow string-based algorithms to work] > My understanding is that email6 in 3.3 will essentially follow that > same model. What I believe RDM is suggesting is an in-between approach > for the 3.2 email module: > > - if you pass in bytes data that isn't 7-bit clean and naively use the > str APIs to access the headers, then it will complain loudly if it is > about to return escaped data (but will decode the body in accordance > with the Content Transfer Encoding) Almost correct. What it will do when it does not have the information needed to decode the bytes correctly (ie: the message is not RFC compliant) is to replace the unknown bytes with '?' characters. This means that you can render a "dirty" email to the terminal, for example, and the invalid bytes will show as '?'s.[*] > - if you pass in bytes data and know what you are doing, then you can > access that raw bytes data and do your own decoding With the current patch this is a true statement for message bodies, but not for message headers. There is no easy way to add access to the bytes version of headers to the email5 API, but since any such data would be non-RFC compliant anyway, that will just have to be good enough for now. > I've probably grossly oversimplified what RDM is suggesting, but it > sounds plausible as a useful interim stepping stone to the more > comprehensive type separation in email6. The more I look at the patch the more I think this can be an internal implementation detail in email5 just like you might do for urllib. So the email5 API will have a way to put bytes in, a way to get decoded data out, and a way to get a bytes out (except for individual header values). The model object will be the same no matter what you put in or take out. The additional methods added to the email5 API to make this possible will be: message_from_bytes (and Parser.parsebytes) message_from_binary_file Feedparser.feedbytes BytesGenerator message_from_bytes and message_from_binary_file are currently part of the proposed email6 API, and I was thinking about some version of Feedparser.feedbytes[**]. BytesGenerator wasn't, but now perhaps it will be (and certainly will be in the backward compatibility interface). -- R. David Murray www.bitdance.com [*] Why '?' and not the unicode invalid character character? Well, the email5 Generate.flatten can be used to generate data for transmission over the wire *if* the source is RFC compliant and 7bit-only, and this would be a normal email5 usage pattern (that is, smtplib.SMTP.sendmail expects ASCII-only strings as input!). So the data generated by Generator.flatten should not include unicode...which raises a problem for CTE 8bit sections that the patch doesn't currently address. [**] Benjamin asked how the patch would affect backward compatibility support in email6, and I said it wouldn't make it harder. However, if feedbytes calls can be mixed with feed calls, which in the simplest implementation they could be, then if email6 does *not* use surrogates internally its feedparser algorithm would need to be considerably more complicated to be backward compatible with this. So when I add Feedparser.parsebytes to my patch, I am at least initially going to disallow mixing calls to feed and feedbytes. Which is another reason to add that method so as to keep the use of the surrogateescape an implementation detail. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who wants to donate an AMD64 Linux build slave?
I can probably run a build slave on one of my boxes (Gentoo, Athlon 64 x2). Where are the setup docs? http://wiki.python.org/moin/BuildBot Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who wants to donate an AMD64 Linux build slave?
On Tue, Oct 5, 2010 at 17:06, "Martin v. Löwis" wrote: >> I can probably run a build slave on one of my boxes (Gentoo, Athlon 64 >> x2). Where are the setup docs? > > http://wiki.python.org/moin/BuildBot Cool, can you get me username/passwd? Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rietveld integration into Roundup
I feel that, only if a roundup issue has patch, the corresponding rietveld issue be created, it is more helpful there and avoids needless duplication. I have changed that now. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
On Tue, Oct 5, 2010 at 4:56 PM, Darren Dale wrote:
> from ...sys import path
>
> Note that while that last case is legal, it is certainly
> discouraged ("insane" was the word Guido used).
Only if by "legal" you mean "happened to work". It stops "happening to
work" in Python 2.6.6. :)
Generally I'm +0 on relative imports as a whole.
Schiavo
Simon
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
On 05/10/2010 17:13, Simon Cross wrote:
On Tue, Oct 5, 2010 at 4:56 PM, Darren Dale wrote:
from ...sys import path
Note that while that last case is legal, it is certainly
discouraged ("insane" was the word Guido used).
Only if by "legal" you mean "happened to work". It stops "happening to
work" in Python 2.6.6. :)
Generally I'm +0 on relative imports as a whole.
As the OP pointed out, for code that may be *included* in other projects
there is no other choice. This is often useful for packages shared
between one or two projects that nonetheless don't warrant separate
distribution.
All the best,
Michael
Schiavo
Simon
___
Python-Dev mailing list
[email protected]
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/blog
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
On Tue, 05 Oct 2010 17:18:18 +0100 Michael Foord wrote: > > > > Generally I'm +0 on relative imports as a whole. > > As the OP pointed out, for code that may be *included* in other projects > there is no other choice. This is often useful for packages shared > between one or two projects that nonetheless don't warrant separate > distribution. You can put several packages in a single distribution. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] stable builders
On Tue, 05 Oct 2010 17:06:40 +0200 "Martin v. Löwis" wrote: > > I can probably run a build slave on one of my boxes (Gentoo, Athlon 64 > > x2). Where are the setup docs? > > http://wiki.python.org/moin/BuildBot By the way, is the distinction between "stable" and "unstable" builders still relevant? If I look at http://www.python.org/dev/buildbot/3.x.stable/, two of our four stable builders are offline (and at least one of them - the ia64 one - has been for a long time). Granted, this makes them "stable" in a sense ;) Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Pythonmac-SIG] sad state of OS X Python testing...
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. If its still needed, I can set up buildbot to run on it today. Is it all pull/poll oriented, or does the slave need to be connected to by the master? Meaning, do I need to poke a hole in the firewall to allow any external access? The BuildBot page only mentions outgoing access (or I'm misunderstanding it). IIUC, I just need a name/password to tell buildbot to connect to, right? -- Stephen ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] issue 9807 - a glitch in coexisting builds of different types
-On [20101005 16:21], Barry Warsaw ([email protected]) wrote: >Do any BSD distros provide multiple different builds of Python to their users? For all I can tell, no. Assuming you are referring to different builds of the same version. >How do they handle having a debug build or non-debug build? Install in the same place. So you either install a debug build or a stripped build. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B The fragrance always stays in the hand that gives the rose... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
On Tue, Oct 5, 2010 at 12:43 PM, Antoine Pitrou wrote: > On Tue, 05 Oct 2010 17:18:18 +0100 > Michael Foord wrote: >> > >> > Generally I'm +0 on relative imports as a whole. >> >> As the OP pointed out, for code that may be *included* in other projects >> there is no other choice. This is often useful for packages shared >> between one or two projects that nonetheless don't warrant separate >> distribution. > > You can put several packages in a single distribution. Thats not the point though. Due to compatibility issues, maybe I don't want to expose the code at the top level. Maybe the foo package is distributed elsewhere as a top-level package, but I need to use an older version due to compatibility problems. I certainly don't want to risk overwriting a pre-existing installation of foo with my required version of foo. This is not a hypothetical, we once had exactly this problem when we distributed an old version of enthought.traits with matplotlib (even though we checked for pre-existing installations, crufty build/ directories containing the out-of-date traits package were overwriting existing installations). Darren ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
Le mardi 05 octobre 2010 à 13:28 -0400, Darren Dale a écrit : > >> > >> As the OP pointed out, for code that may be *included* in other projects > >> there is no other choice. This is often useful for packages shared > >> between one or two projects that nonetheless don't warrant separate > >> distribution. > > > > You can put several packages in a single distribution. > > Thats not the point though. Due to compatibility issues, maybe I don't > want to expose the code at the top level. Maybe the foo package is > distributed elsewhere as a top-level package, but I need to use an > older version due to compatibility problems. I certainly don't want to > risk overwriting a pre-existing installation of foo with my required > version of foo. This is not a hypothetical, we once had exactly this > problem when we distributed an old version of enthought.traits with > matplotlib That use case requires that the third-party package, not your package, use relative imports. I don't think you can require other projects to follow your coding style recommendations (unless of course you maintain both). And of course you can simply set sys.path to point to your private copies of vendor libraries. Or you can manually import them using the "imp" module. > (even though we checked for pre-existing installations, > crufty build/ directories containing the out-of-date traits package > were overwriting existing installations). I'm not sure I understand the issue. If there's a distutils bug you can report it on http://bugs.python.org. In the end, I think Python offers enough packaging and module locating/loading options that relative imports shouldn't be used just for "distribution purposes". Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
> If they were actively discouraged, perhaps performing a relative > import would raise a warning, This would be done if this import style was deprecated. It’s different from it being discouraged. > or maybe distutils would raise a warning at install time, Distutils does not inspect source files. > Up until now, I was not aware that use of PEP 328 relative imports > might be discouraged. I'm still unclear as to why they might be > discouraged. I think relative imports are a nice thing. I think they’ve been added because there are people who want them, and the previous implicit relative imports caused so much pain. Neither the FAQ you quote nor PEP 8 really explain what’s bad about explicit relative imports. Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rietveld integration into Roundup
I followed the review link from issue5109 to arrive at http://bugs.python.org/review/5109/patch/179/325 . On the review page I clicked on Modules/arraymodule.c > View for side-by-side diff and got Error fetching None/Modules/arraymodule.c?rev=83179: InvalidURLError: Protocol '%s' is not supported. On the other hand, the unified diff link works. Note that the "Tracker Branch" shows /branches/release27-maint even though the patch is for py3k. On Tue, Oct 5, 2010 at 11:31 AM, "Martin v. Löwis" wrote: > >> I feel that, only if a roundup issue has patch, the corresponding >> rietveld issue be created, it is more helpful there and avoids >> needless duplication. > > I have changed that now. > > Regards, > Martin > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/alexander.belopolsky%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
On Tue, Oct 5, 2010 at 1:45 PM, Antoine Pitrou wrote: > Le mardi 05 octobre 2010 à 13:28 -0400, Darren Dale a écrit : >> >> >> >> As the OP pointed out, for code that may be *included* in other projects >> >> there is no other choice. This is often useful for packages shared >> >> between one or two projects that nonetheless don't warrant separate >> >> distribution. >> > >> > You can put several packages in a single distribution. >> >> Thats not the point though. Due to compatibility issues, maybe I don't >> want to expose the code at the top level. Maybe the foo package is >> distributed elsewhere as a top-level package, but I need to use an >> older version due to compatibility problems. I certainly don't want to >> risk overwriting a pre-existing installation of foo with my required >> version of foo. This is not a hypothetical, we once had exactly this >> problem when we distributed an old version of enthought.traits with >> matplotlib > > That use case requires that the third-party package, not your package, > use relative imports. I don't think you can require other projects to > follow your coding style recommendations (unless of course you maintain > both). I'm not talking about requiring other projects to follow my coding style. > I'm not sure I understand the issue. The issue is implementing a PEP with nice support for relative imports, and then documenting that it should never be used. Darren ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding Wing 4 project to
On 05/10/2010 13:00, Antoine Pitrou wrote: On Tue, 05 Oct 2010 12:39:00 +0100 Michael Foord wrote: 1. rename the old file 'python-wing3.wpr' and rename 'python-wing4.wpr' to 'python-wing.wpr' 2. delete the wing 3 project file altogether and rename 'python-wing4.wpr' to 'python-wing.wpr' 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'll give it a bit more time, but in the absence of dissenting opinions (a rare thing on python-dev) I'll go ahead and do this. At least it can be done now. All the best, Michael Regards Antoine. ___ Python-Dev mailing list [email protected] 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/blog 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
On Tue, 5 Oct 2010 14:17:47 -0400 Darren Dale wrote: > >> Thats not the point though. Due to compatibility issues, maybe I don't > >> want to expose the code at the top level. Maybe the foo package is > >> distributed elsewhere as a top-level package, but I need to use an > >> older version due to compatibility problems. I certainly don't want to > >> risk overwriting a pre-existing installation of foo with my required > >> version of foo. This is not a hypothetical, we once had exactly this > >> problem when we distributed an old version of enthought.traits with > >> matplotlib > > > > That use case requires that the third-party package, not your package, > > use relative imports. I don't think you can require other projects to > > follow your coding style recommendations (unless of course you maintain > > both). > > I'm not talking about requiring other projects to follow my coding style. Then can you explain your use case a bit better? It is not obvious at all what kind of "solution" relative imports allow, and why not using them is a heavy burden. > > I'm not sure I understand the issue. > > The issue is implementing a PEP with nice support for relative > imports, and then documenting that it should never be used. While I haven't written the FAQ, I certainly sympathize with the idea that relative imports are much less readable than absolute imports (especially when they climb upwards in the directory hierarchy, i.e. "from ..foo import bar"). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
On Tue, Oct 5, 2010 at 11:17 AM, Darren Dale wrote: > The issue is implementing a PEP with nice support for relative > imports, and then documenting that it should never be used. Isn't this mostly historical? Until the new relative-import syntax was implemented there were various problems with relative imports. The short-term solution was to recommend not using them. The long-term solution was to implement an unambiguous syntax. Now it is time to withdraw the anti-recommendation. Of course, without going overboard -- I still find them an acquired taste; but they have their place. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Pythonmac-SIG] sad state of OS X Python testing...
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. If its still needed, I can set up buildbot to run on it today. That would be nice. Is it all pull/poll oriented, or does the slave need to be connected to by the master? It uses Perspective Broker, if that's of any help. The slave creates an outgoing TCP connection (which should be kept up all the time), but the master pushes commands over that connection, no polling. IIUC, I just need a name/password to tell buildbot to connect to, right? Correct. However, I wouldn't want to create that unless you had all the software in place already - else I find myself often waiting for some time, then removing the slave again. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rietveld integration into Roundup
Am 05.10.10 20:15, schrieb Alexander Belopolsky: I followed the review link from issue5109 to arrive at http://bugs.python.org/review/5109/patch/179/325 . On the review page I clicked on Modules/arraymodule.c> View for side-by-side diff and got Error fetching None/Modules/arraymodule.c?rev=83179: InvalidURLError: Protocol '%s' is not supported. That currently happens for a lot of patches. It can't figure out what the base branch is, and goes to the Rietveld Issue object - on which it is None (because I believe Rietveld is misguided in associating base URLs with issues - they belong to patchsets, as different patches on the same issues might work on different branches). On the other hand, the unified diff link works. It already has the unified diff - just not the base text that it was generated from (and hence also not the new text). Note that the "Tracker Branch" shows /branches/release27-maint even though the patch is for py3k. Yes - it miscomputed it, based on the revision number in the patch (which was a revision in which 2.7 was modified). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
On 10/5/2010 2:21 PM, Guido van Rossum wrote: On Tue, Oct 5, 2010 at 11:17 AM, Darren Dale wrote: The issue is implementing a PEP with nice support for relative imports, and then documenting that it should never be used. Isn't this mostly historical? Until the new relative-import syntax was implemented there were various problems with relative imports. The short-term solution was to recommend not using them. The long-term solution was to implement an unambiguous syntax. Now it is time to withdraw the anti-recommendation. Of course, without going overboard -- I still find them an acquired taste; but they have their place. Darren, if you have not yet done so, open a tracker that quotes the above and gives your recommended changes at which locations. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
On Tue, Oct 5, 2010 at 3:37 PM, Terry Reedy wrote: > On 10/5/2010 2:21 PM, Guido van Rossum wrote: >> >> On Tue, Oct 5, 2010 at 11:17 AM, Darren Dale wrote: >>> >>> The issue is implementing a PEP with nice support for relative >>> imports, and then documenting that it should never be used. >> >> Isn't this mostly historical? Until the new relative-import syntax was >> implemented there were various problems with relative imports. The >> short-term solution was to recommend not using them. The long-term >> solution was to implement an unambiguous syntax. Now it is time to >> withdraw the anti-recommendation. Of course, without going overboard >> -- I still find them an acquired taste; but they have their place. > > Darren, if you have not yet done so, open a tracker that quotes the above > and gives your recommended changes at which locations. Done: http://bugs.python.org/issue10031 Darren ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stable builders
Am 05.10.10 19:07, schrieb Antoine Pitrou: On Tue, 05 Oct 2010 17:06:40 +0200 "Martin v. Löwis" wrote: I can probably run a build slave on one of my boxes (Gentoo, Athlon 64 x2). Where are the setup docs? http://wiki.python.org/moin/BuildBot By the way, is the distinction between "stable" and "unstable" builders still relevant? It's still formally the requirement for making releases. If I look at http://www.python.org/dev/buildbot/3.x.stable/, two of our four stable builders are offline (and at least one of them - the ia64 one - has been for a long time). Granted, this makes them "stable" in a sense ;) I guess somebody would need to do monitoring on them, and ping operators if the buildbot is down for an extended period of time. Feel free to ping any operator whenever you notice that a slave is down (they do get an automated email, but people can get resistant to automated emails). Also, if you would want to propose that a different set than the current ones should be considered stable, please let me know. I believe "stable" was meant in a different way, though - it would reliably pass all tests, and a test failure should be considered a bug, rather than some random failure on the slave. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
On Wed, Oct 6, 2010 at 4:21 AM, Guido van Rossum wrote: > On Tue, Oct 5, 2010 at 11:17 AM, Darren Dale wrote: >> The issue is implementing a PEP with nice support for relative >> imports, and then documenting that it should never be used. > > Isn't this mostly historical? Until the new relative-import syntax was > implemented there were various problems with relative imports. The > short-term solution was to recommend not using them. The long-term > solution was to implement an unambiguous syntax. Now it is time to > withdraw the anti-recommendation. Of course, without going overboard > -- I still find them an acquired taste; but they have their place. Indeed, the objections raised in those FAQ entries mostly applied to the problems implicit relative imports could silently cause. Explicit relative imports will throw exceptions for those cases instead. They read like someone took the old text and just modified it to refer to explicit imports instead of implicit ones without softening the language at all. The remaining scenarios we have that can lead to duplication of a module happen regardless of the import style you use*. Cheers, Nick. *For the curious - those scenarios relate to ending up with the same module present both as "__main__" and under its normal module name. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stable builders
On Wed, Oct 6, 2010 at 6:55 AM, "Martin v. Löwis" wrote: > I guess somebody would need to do monitoring on them, and ping operators > if the buildbot is down for an extended period of time. Feel free to ping > any operator whenever you notice that a slave is down (they do get > an automated email, but people can get resistant to automated emails). > > Also, if you would want to propose that a different set than the current > ones should be considered stable, please let me know. I believe > "stable" was meant in a different way, though - it would reliably pass all > tests, and a test failure should be considered a bug, rather than > some random failure on the slave. To simplify the task of contacting buildbot operators, would it be worth having a "python-buildbot-owners" mailing list? Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stable builders
To simplify the task of contacting buildbot operators, would it be worth having a "python-buildbot-owners" mailing list? Depends on the traffic. It might spam those owners who are never the target of any of these messages, because they are "well-behaving". Do you really find it difficult to determine the email address of any specific operator? Who? If you really need to broadcast a message to all owners, let me know and I can forward it to them (or you can collect the addresses yourself). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stable builders
On Tue, 05 Oct 2010 22:55:41 +0200 "Martin v. Löwis" wrote: > > I guess somebody would need to do monitoring on them, and ping operators > if the buildbot is down for an extended period of time. Feel free to > ping any operator whenever you notice that a slave is down (they do get > an automated email, but people can get resistant to automated emails). Well, I suppose manual pinging can become pretty much like automated emails if it becomes frequent. (in any case, I think I've pinged Matthias at least twice on IRC, but perhaps he isn't really present on that medium, although he doesn't appear away) > Also, if you would want to propose that a different set than the current > ones should be considered stable, please let me know. I believe > "stable" was meant in a different way, though - it would reliably pass > all tests, and a test failure should be considered a bug, rather than > some random failure on the slave. I see. Well, apart from the current ones, "alpha Debian" and "i386 Ubuntu" have been quite stable. Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
On Wed, Oct 06, 2010 at 07:09:48AM +1000, Nick Coghlan wrote: > The remaining scenarios we have that can lead to duplication of a > module happen regardless of the import style you use*. > > Cheers, > Nick. > > *For the curious - those scenarios relate to ending up with the same > module present both as "__main__" and under its normal module name. I remember falling in the trap of importing the same module twice by manipulating sys.path and changing cwd (current working directory); the module was imported from different paths - from the current directory (entry '.' in the sys.path) and by its full path. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question/comment about documentation of relative imports
Guido van Rossum wrote: Now it is time to withdraw the anti-recommendation. Or at least re-word them all to make it clear that they're talking about the *old* style of relative import in 2.x. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rietveld integration into Roundup
On Tue, Oct 5, 2010 at 3:25 PM, "Martin v. Löwis" wrote: .. >> >> Error fetching None/Modules/arraymodule.c?rev=83179: InvalidURLError: >> Protocol '%s' is not supported. > > That currently happens for a lot of patches. It can't figure out what > the base branch is, and goes to the Rietveld Issue object - on which > it is None (because I believe Rietveld is misguided in associating > base URLs with issues - they belong to patchsets, as different patches > on the same issues might work on different branches). > I attempted to fix the branch at http://bugs.python.org/file18220 , but it did not trigger rietveld update. I assume you made "Tracker Branch" editable on purpose, but there should be a way rietveld side to know when this field is changed I think. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch making the current email package (mostly) support bytes
Nick Coghlan writes: > - if you pass in bytes data and know what you are doing, then you can > access that raw bytes data and do your own decoding At what level, though? To take an interesting example I used to see frequently: From: [email protected] (Taro Yamada in 8-bit Shift JIS) So I guess you are suggesting that the email module can RFC 822 parse that, and 1. Refuse to return the unwrapped (ie, single line) form of the whole field, except as bytes. 2. Refuse to return the content of the From field, except as bytes. 3. Return the email address parsed from the From field. 4. Refuse to return the comment, except as bytes. That's fine. But suppose I have a private or newly defined header that is structured? Now I have two choices: 1. Write a version of my private parser for both str (the normal case) and bytes (if accessing the value as str raises) 2. Always get the bytes and convert them to str (probably using the same .decode('ascii','surrogate-escape') call that email uses but won't let me have the value of!), then use a common str parser. Note that this is more problematic than it looks, since the appropriate base codec may require information from higher-level structures (eg, qp codec tags or a Content-Type header's charset field). Why should I reproduce email's logic here? I don't care if the default or concise API raises on surrogates in the str value. But I'm pretty sure that I will want to use str values containing surrogates in these contexts (for the same reasons that email module does, for example), rather than work with bytes sometimes and strs sometimes. Please provide a way to return strs-with-surrogates if I ask for them. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rietveld integration into Roundup
I attempted to fix the branch at http://bugs.python.org/file18220 , but it did not trigger rietveld update. I assume you made "Tracker Branch" editable on purpose, but there should be a way rietveld side to know when this field is changed I think. Please start submitting issues with the Rietveld integration into the meta tracker. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
