Re: [Python-Dev] Should collections.Counter check for int?
I'd prefer Counter to refuse non-numerical values right away as the present behaviour may hide bugs (e.g. a forgotten string->int conversion). Any opinions? (And what about negative values or floats?) Please file a report on bugs.python.org so that there's a record of this issue. Done: http://bugs.python.org/issue6038 - Hagen ___ 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] .pth files should never contain python
Paul Moore wrote: 2009/5/9 Chris Withers : Martin v. Löwis wrote: I thought .pth files just had python in them? Not at all - they never did. They have paths in them. I've certainly seen them with python in, and that's what I hate about them... AIUI, there was a small special case that lines starting with "import" are executed (see the source of site.py for details). This exception has been exploited (some would say "abused", but I'm trying to be unbiased here) by setuptools, at least, to do path manipulations and such. Abused is definitely the right word, I suppose it's too late to correct this bug? How about for Python 3? cheers, 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] PEP 376 : Changing the .egg-info structure
Ok I've changed the PEP with all the points you mentioned, if you want to take a look. 2009/5/15 P.J. Eby : > Next, the doc for the metadata API functions seems quite sparse. ISTR that > I've previously commented on such issues as case- and > punctuation-insensitivity of project names, and '/' separation in egg_info > subpaths, but these don't seem to have been incorporated into the current > version of the PEP. > > These are important considerations in general, btw, because project name and > version canonicalization and escaping are an important part of both > generating and parsing .egg-info filenemaes. At minimum, the relevant > setuptools docs that define these standards should be cited. I need to find back your comments for this part, I must have missed them. That's the last part I didn't work out yet on the current PEP revision. Regards Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 : Changing the .egg-info structure
Yes, I don't think it's relevant to optimize install/uninstall code in Python. In the whole PEP 376 proposal, the only part that will need care will be the code that browses sys.path. On Fri, May 15, 2009 at 9:50 AM, Dirkjan Ochtman wrote: > On Fri, May 15, 2009 at 8:32 AM, Jeroen Ruigrok van der Werven > wrote: >> Agreed. Within FreeBSD's ports the installed package registration gets a MD5 >> hash per file recorded. Size is less interesting though, since essentially >> this information is encapsulated within the hash. Remove one byte from the >> file and your hash is already different. And the case of a collision for >> this kind of registration is sufficiently small to need the size >> information. > > Size is nice because it's much cheaper to check. I don't know if mass > uninstalls will be so common that this is actually something we have > to worry about, though. > > 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/ziade.tarek%40gmail.com > -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 : Changing the .egg-info structure
At 06:06 PM 5/16/2009 +0200, Tarek Ziadé wrote: Ok I've changed the PEP with all the points you mentioned, if you want to take a look. Some notes: 1. Why ';' separation, instead of tabs as in PEP 262? Aren't semicolons a valid character in filenames? 2. "if the installed file is located in a directory in site-packages" should refer not to site-packages but to the directory containing the .egg-info directory. 3. get_egg_info_file needs to be specified as using '/'-separated paths and converting to OS paths if appropriate. There's also the problem that the mode it opens the file in (binary or text) is unspecified. 4. There should probably be a way to iterate over the projects in a directory, since it's otherwise impossible for an installation tool to find out what project(s) "own" a file that conflicts with something being installed. Alternatively, reshaping the file API to allow querying by path as well as by project might work. 5. If any cache mechanisms are to be used by the API, the API *must* make it possible to bypass or explicitly manage that cache, as otherwise installation tools and tools that manipulate sys.path at runtime may end up using incorrect data. 6. get_files() doesn't document whether the yielded paths are absolute or relative, local or cross-platform, etc. I need to find back your comments for this part, I must have missed them. That's the last part I didn't work out yet on the current PEP revision. Well, if you can't find them, the EggFormats doc explains how these file/dir structures are currently laid out by setuptools, easy_install, pip, etc., and the PEP should probably reference that. Technically, this PEP doesn't so much propose a change to the EggFormats standard, as simply add a RECORD file to it, and propose stdlib support for reading and writing it. So, the PEP really should reference (i.e. link to) the existing standard. The EggFormats doc in turn cites pkg_resources doc for lower-level format issues, such as name and version normalization, filename escaping, file parsing, etc. This PEP should also probably be framed as a replacement for PEP 262, proposing to extend the de-facto standard for an installation database with uninstall support, and blessing selected portions of the de facto standard as an official standard. (Since that's pretty much exactly what it is.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 : Changing the .egg-info structure
On approximately 5/16/2009 9:55 AM, came the following characters from the keyboard of P.J. Eby: At 06:06 PM 5/16/2009 +0200, Tarek Ziadé wrote: Ok I've changed the PEP with all the points you mentioned, if you want to take a look. Some notes: 1. Why ';' separation, instead of tabs as in PEP 262? Aren't semicolons a valid character in filenames? Why tabs? Aren't tabs a valid character in filenames? (hint: Both are valid in POSIX filenames, neither are valid in Windows filenames) -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 : Changing the .egg-info structure
At 11:17 AM 5/16/2009 -0700, Glenn Linderman wrote: On approximately 5/16/2009 9:55 AM, came the following characters from the keyboard of P.J. Eby: At 06:06 PM 5/16/2009 +0200, Tarek Ziadé wrote: Ok I've changed the PEP with all the points you mentioned, if you want to take a look. Some notes: 1. Why ';' separation, instead of tabs as in PEP 262? Aren't semicolons a valid character in filenames? Why tabs? Aren't tabs a valid character in filenames? (hint: Both are valid in POSIX filenames, neither are valid in Windows filenames) ";" *is* valid in Windows filenames, actually. Tabs aresn't. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 : Changing the .egg-info structure
On approximately 5/16/2009 11:58 AM, came the following characters from the keyboard of P.J. Eby: At 11:17 AM 5/16/2009 -0700, Glenn Linderman wrote: On approximately 5/16/2009 9:55 AM, came the following characters from the keyboard of P.J. Eby: At 06:06 PM 5/16/2009 +0200, Tarek Ziadé wrote: Ok I've changed the PEP with all the points you mentioned, if you want to take a look. Some notes: 1. Why ';' separation, instead of tabs as in PEP 262? Aren't semicolons a valid character in filenames? Why tabs? Aren't tabs a valid character in filenames? (hint: Both are valid in POSIX filenames, neither are valid in Windows filenames) ";" *is* valid in Windows filenames, actually. Tabs aresn't. Oops. Guess I got that crossed with valid email address characters... But I should probably have stated my point... that since there are no characters that are not illegal in file names on every platform, except "/" and NULL, that some mention should be made, that splitting the line on ; (or TAB) isn't necessarily the correct parsing technique... rather that the line should be parsed from the right end, and the remainder used as a the filename, as the numbers at the end would not have ; or TAB as legal characters within them. Or else some escaping mechanism needs to be defined. Or else the ; or TAB will be illegal in names used in the RECORD (which would be limiting, although not significantly so, in my opinion, but others may have other opinions). -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 : Changing the .egg-info structure
В Сбт, 16/05/2009 в 14:58 -0400, P.J. Eby пишет: > ";" *is* valid in Windows filenames, actually. Tabs aresn't. I was sure ';' is separator for PATH in Windows. Do I miss something? If I remember right os.path.pathsep is ';' under Windows. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 : Changing the .egg-info structure
Alexander Shigin wrote: > В Сбт, 16/05/2009 в 14:58 -0400, P.J. Eby пишет: >> ";" *is* valid in Windows filenames, actually. Tabs aresn't. > > I was sure ';' is separator for PATH in Windows. Do I miss something? Yes, this: http://msdn.microsoft.com/en-us/library/aa365247.aspx 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] PEP 376 : Changing the .egg-info structure
On approximately 5/16/2009 1:08 PM, came the following characters from the keyboard of Martin v. Löwis: Alexander Shigin wrote: В Сбт, 16/05/2009 в 14:58 -0400, P.J. Eby пишет: ";" *is* valid in Windows filenames, actually. Tabs aresn't. I was sure ';' is separator for PATH in Windows. Do I miss something? Yes, this: http://msdn.microsoft.com/en-us/library/aa365247.aspx Well, maybe he was missing that, or maybe he was missing that each entry in the Windows PATH is allowed to be quoted, so that ; characters inside quotes are part of path names, and ; characters outside of quotes are separators. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 : Changing the .egg-info structure
Glenn Linderman wrote: On approximately 5/16/2009 11:58 AM, came the following characters from the keyboard of P.J. Eby: At 11:17 AM 5/16/2009 -0700, Glenn Linderman wrote: On approximately 5/16/2009 9:55 AM, came the following characters from the keyboard of P.J. Eby: At 06:06 PM 5/16/2009 +0200, Tarek Ziadé wrote: Ok I've changed the PEP with all the points you mentioned, if you want to take a look. Some notes: 1. Why ';' separation, instead of tabs as in PEP 262? Aren't semicolons a valid character in filenames? Why tabs? Aren't tabs a valid character in filenames? (hint: Both are valid in POSIX filenames, neither are valid in Windows filenames) ";" *is* valid in Windows filenames, actually. Tabs aresn't. Oops. Guess I got that crossed with valid email address characters... But I should probably have stated my point... that since there are no characters that are not illegal in file names on every platform, except "/" and NULL, that some mention should be made, that splitting the line on ; (or TAB) isn't necessarily the correct parsing technique... rather that the line should be parsed from the right end, and the remainder used as a the filename, as the numbers at the end would not have ; or TAB as legal characters within them. Or else some escaping mechanism needs to be defined. Or else the ; or TAB will be illegal in names used in the RECORD (which would be limiting, although not significantly so, in my opinion, but others may have other opinions). FYI, on RISC OS '/' is a valid filename character and '.' is used as the directory separator. I'd probably say that TAB is s reasonable character to use, even though it's OK in POSIX; after all, should anyone really be using a control character in a filename? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 : Changing the .egg-info structure
MRAB mrabarnett.plus.com> writes: > > I'd probably say that TAB is s reasonable character to use, even though > it's OK in POSIX; after all, should anyone really be using a control > character in a filename? Even newline characters are valid characters in a filename. Why not go for the safe choice of encoding all filenames using e.g. urllib.quote()? (which has the advantage that usual filenames will stay perfectly readable) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 : Changing the .egg-info structure
В Сбт, 16/05/2009 в 13:26 -0700, Glenn Linderman пишет: > On approximately 5/16/2009 1:08 PM, came the following characters from > the keyboard of Martin v. Löwis: > > Yes, this: > > > > http://msdn.microsoft.com/en-us/library/aa365247.aspx > > Well, maybe he was missing that, or maybe he was missing that each entry > in the Windows PATH is allowed to be quoted, so that ; characters inside > quotes are part of path names, and ; characters outside of quotes are > separators. Yep, I haven't think about it. MSDN entry makes clean that ';' is valid for file name. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 : Changing the .egg-info structure
В Сбт, 16/05/2009 в 23:15 +0100, MRAB пишет: > FYI, on RISC OS '/' is a valid filename character and '.' is used as > the directory separator. > > I'd probably say that TAB is s reasonable character to use, even > though it's OK in POSIX; after all, should anyone really be using a > control character in a filename? The '\0' char is invalid in both windows and posix. I don't know if one valid on RISC OS. ___ 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
[email protected]
Issue 6012 proposes to add cleanup support for O& converters; a first client for this would be PyUnicode_FSConverter. Using cleanup is always necessary if the conversion function allocates memory, and a later argument converter fails. The memory allocated must then be released. There are three options currently to provide such a function: 1. Make a code O&& with two function pointers. I find that too tedious to use. 2. Introduce a new code O$, that takes a O&-style function which, in addition, can also be called with a NULL PyObject*, meaning that it should cleanup. 3. Extend O& so that its function pointers also support the cleanup mode (NULL first argument). Conversion functions that need cleanup would have to return a special constant rather than the usual value of 1. In addition, there is also the approach introduced in issue 5990: 4. Users of a conversion function that requires cleanup need to initialize the output pointer to NULL, and then release memory explicitly when the argument conversion fails. Which of these do you like best? 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
