Re: [Python-Dev] Migration strategy for new-style string formatting [Was: Binary Operator for New-Style String Formatting]
On Jun 21, 2009, at 5:40 PM, Eric Smith wrote:
I've basically come to accept that %-formatting can never go away,
unfortunately. There are too many places where %-formatting is used,
for example in logging Formatters. %-formatting either has to exist
or it has to be emulated.
It'd possibly be helpful if there were builtin objects which forced
the format style to be either newstyle or oldstyle, independent of
whether % or format was called on it.
E.g.
x = newstyle_formatstr("{} {} {}")
x % (1,2,3) == x.format(1,2,3) == "1 2 3"
and perhaps, for symmetry:
y = oldstyle_formatstr("%s %s %s")
y.format(1,2,3) == x % (1,2,3) == "1 2 3"
This allows the format string "style" decision is to be made external
to the API actually calling the formatting function. Thus, it need not
matter as much whether the logging API uses % or .format() internally
-- that only affects the *default* behavior when a bare string is
passed in.
This could allow for a controlled staged towards the new format string
format, with a long deprecation period for users to migrate:
1) introduce the above feature, and recommend in docs that people only
ever use new-style format strings, wrapping the string in
newstyle_formatstr() when necessary for passing to an API which uses %
internally.
2) A long time later...deprecate str.__mod__; don't deprecate
newstyle_formatstr.__mod__.
3) A while after that (maybe), remove str.__mod__ and replace all
calls in Python to % (used as a formatting operator) with .format() so
that the default is to use newstyle format strings for all APIs from
then on.
James
___
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] PEP 376
Hello, We have polished out PEP 376 and its code prototype at Distutils-SIG. It seems to fullfill now all the requirements, so I am mailing it here again, for a new round of feedback, if needed. - the pep : http://svn.python.org/projects/peps/trunk/pep-0376.txt - the code prototype : http://bitbucket.org/tarek/pep376/src/tip/pkgutil.py Notice that if the PEP is accepted at this point, I will : - focus on making the code work as fast as possible, for directories browsing - work on the backport and the required patches for setuptools and pip at the same time, and see if I can get some beta-testers that are willing to switch to this new version to test it extensively before 2.7/3.2 are out. 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
Hello, Tarek Ziadé gmail.com> writes: > > so I am mailing it here again, for a new round of feedback, if needed. > > - the pep : http://svn.python.org/projects/peps/trunk/pep-0376.txt Some comments: - the **MD5** hash of the file, encoded in hex. Notice that `pyc` and `pyo` generated files will not have a hash. Why the exception for pyc and pyo files? - `zlib` and `zlib-2.5.2.egg-info` are located in `site-packages` so the file paths are relative to it. Is it a general rule? That is, the paths in RECORD are always relative to its grandparent directory? The RECORD format - The `RECORD` file is a CSV file, composed of records, one line per installed file. The ``csv`` module is used to read the file, with the `excel` dialect, which uses these options to read the file: - field delimiter : `,` - quoting char : `"`. - line terminator : `\r\n` Wouldn't it be better to use the native line terminator on the current platform? (someone might want to edit or at least view the file) What is the character encoding for non-ASCII filenames? UTF-8? Are the RECORD file's contents somehow part of the DistributionMetadata? - ``DistributionDirectories``: manages ``EggInfoDirectory`` instances. What is an EggInfoDirectory ? A plural class name looks strange (I think it's the first time I see one in the CPython codebase). How about another name? (DistributionPool, DistributionMap, WorkingSet etc.). - ``get_egginfo_file(path, binary=False)`` -> file object Returns a file located under the `.egg-info` directory. Returns a ``file`` instance for the file pointed by ``path``. Is it always a file instance or just a file-like object? (zipped distributions come to mind). Is it opened read-only? - ``owner(path)`` -> ``Distribution`` instance or None If ``path`` is used by only one ``Distribution`` instance, returns it. Otherwise returns None. This is a bit confusing. If it returns None, it doesn't distinguish between the case where several Distributions refer to the path, and the case where no distributions refer to it, does it? Is there any reason to have this method while file_users(path) already exists? A new class called ``DistributionDirectories`` is created. It's a collection of ``DistributionDirectory`` and ``ZippedDistributionDirectory`` instances. The constructor takes one optional argument ``use_cache`` set to ``True`` by default. You forgot to describe the constructor's signature and what it does exactly. ``EggInfoDirectories`` also provides the following methods besides the ones from ``dict``:: What is EggInfoDirectories? - ``append(path)`` Creates an ``DistributionDirectory`` (or ``ZippedDistributionDirectory``) instance for ``path`` and adds it in the mapping. - ``load(paths)`` Creates and adds ``DistributionDirectory`` (or ``ZippedDistributionDirectory``) instances corresponding to ``paths``. Why are these methods named completely differently although they do almost the same thing? Besides, append() makes it look like ordering matters. Does it? (for a naming suggestion, e.g. load(path) and load_all(paths). Or, even simpler, load(*paths) or load(paths)) - ``get_file_users(path)`` -> Iterator of ``Distribution`` (or ``ZippedDistribution``) instances. This method is named file_users in another class. Perhaps the naming should be consistent? All these functions use the same global instance of ``DistributionDirectories`` to use the cache. Is the global instance available to users? >>> for path, hash, size in dist.get_installed_files():: ... print '%s %s %d %s' % (path, hash, size) There's one too many "%s" here. Thanks for your work! 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] PEP 376
On Mon, Jun 22, 2009 at 4:59 PM, Antoine Pitrou wrote: > - the **MD5** hash of the file, encoded in hex. Notice that `pyc` and > `pyo` >generated files will not have a hash. > > Why the exception for pyc and pyo files? As in PEP 262, since they are produced automatically from a py file, checking the py file is enough to decide if the file has changed. > > - `zlib` and `zlib-2.5.2.egg-info` are located in `site-packages` so the > file >paths are relative to it. > > Is it a general rule? That is, the paths in RECORD are always relative to > its > grandparent directory? no, they can be located anywhere on the system. But when the paths are located in the same directory where the .egg-info directory is located, a relative path is used. (see the section before this example) I'll add an example that contains files located elswhere in the system (like a script and a data file) > > > The RECORD format > - > > The `RECORD` file is a CSV file, composed of records, one line per > installed file. The ``csv`` module is used to read the file, with > the `excel` dialect, which uses these options to read the file: > > - field delimiter : `,` > - quoting char : `"`. > - line terminator : `\r\n` > > Wouldn't it be better to use the native line terminator on the current > platform? (someone might want to edit or at least view the file) Good idea, I'll change that, > > > What is the character encoding for non-ASCII filenames? UTF-8? > Yes, there's a constant in Distutils, called PKG_INFO_ENCODING that will be used for the file generation. > > Are the RECORD file's contents somehow part of the DistributionMetadata? The DistributionMetadata correspond to the fields defined in PEP 345, e.g. written in the PKG-INFO file, which is mentioned in the RECORD file. We are reworking PEP 345 as well, to add some fields. What did you have in mind ? > > > - ``DistributionDirectories``: manages ``EggInfoDirectory`` instances. > > What is an EggInfoDirectory ? Typo (old name), fixing this.. > > > A plural class name looks strange (I think it's the first time I see one in > the CPython codebase). How about another name? (DistributionPool, > DistributionMap, WorkingSet etc.). Sure, WorkingSet is nice, it's the name used in setuptools, > > > - ``get_egginfo_file(path, binary=False)`` -> file object > > Returns a file located under the `.egg-info` directory. > > Returns a ``file`` instance for the file pointed by ``path``. > > Is it always a file instance or just a file-like object? (zipped > distributions > come to mind). Is it opened read-only? It's in read-only mode, either "r" either "rb" and in case of a zip file, it returns a file-like object using zipfile.ZipFile.open. > > - ``owner(path)`` -> ``Distribution`` instance or None > >If ``path`` is used by only one ``Distribution`` instance, returns it. >Otherwise returns None. > > This is a bit confusing. If it returns None, it doesn't distinguish between > the > case where several Distributions refer to the path, and the case where no > distributions refer to it, does it? > The idea of this API is to find out of a distribution "owns" a file, e.g. is the only distribution that uses it, so it can be safely removed. > Is there any reason to have this method while file_users(path) already > exists? > Its just a helper for uninstallers, but file_users() could probably be enough, I can remove "owns" if people find it confusing, > A new class called ``DistributionDirectories`` is created. It's a > collection of > ``DistributionDirectory`` and ``ZippedDistributionDirectory`` instances. > The constructor takes one optional argument ``use_cache`` set to ``True`` > by > default. > > You forgot to describe the constructor's signature and what it does > exactly. > I'll add that, > > ``EggInfoDirectories`` also provides the following methods besides the > ones > from ``dict``:: > > What is EggInfoDirectories? This is a DistributionDirectories, one more instance I forgot to rename, I'll fix that > > > - ``append(path)`` > >Creates an ``DistributionDirectory`` (or > ``ZippedDistributionDirectory``) >instance for ``path`` and adds it in the mapping. > > - ``load(paths)`` > >Creates and adds ``DistributionDirectory`` (or >``ZippedDistributionDirectory``) instances corresponding to ``paths``. > > Why are these methods named completely differently although they do almost > the > same thing? Besides, append() makes it look like ordering matters. Does it? > (for a naming suggestion, e.g. load(path) and load_all(paths). Or, > even simpler, load(*paths) or load(paths)) > Right, I'll fix that, > > - ``get_file_users(path)`` -> Iterator of ``Distribution`` (or >``ZippedDistribution``) instances. > > This method is named file_users in another class. Perhaps the naming should > be > consistent? Right, it used to be get_*, that's a typo. I'll fix it, > > > All these function
Re: [Python-Dev] PEP 376
At 05:42 PM 6/22/2009 +0200, Tarek Ziadé wrote: Wouldn't it be better to use the native line terminator on the current platform? (someone might want to edit or at least view the file) Good idea, I'll change that, As long as the file is always *read* with "U" mode, so that you can't mess it up, especially if the install is to a directory shared between platforms. The idea of this API is to find out of a distribution "owns" a file, e.g. is the only distribution that uses it, so it can be safely removed. This could equally well be done by ``owners(path)``, returning a sequence of zero or more items. Any length <> 1 means the file can't be safely removed. Meanwhile, having the data about all the owners of a file would also be useful for tools that just want to inspect a directory's contents, for example, or to detect conflicts and overwrites. ___ 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] draft pep: backwards compatibility
2009/6/20 Collin Winter : > Is this intended to include performance changes? Clearly no-one will > complain if things simply get faster, but I'm thinking about cases > where, say, a function runs in half the time but uses double the > memory (or vice versa). I don't think we can say anything about those cases before hand. We'll have to decide on a case by case basis. -- Regards, Benjamin ___ 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] final release procedure
Hi everyone, We're almost to the finish line on 3.1! Assuming that the last release blocker [1] gets ironed out and no more rear their ugly heads, I will go ahead. I'm going to freeze and tag the tree on Friday at about 15:00 UTC in order for the binaries to be built and uploaded. The release announcement should be the next day. [1] http://bugs.python.org/issue6233 -- Regards, Benjamin ___ 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
A plural class name looks strange (I think it's the first time I see one in the CPython codebase). How about another name? (DistributionPool, DistributionMap, WorkingSet etc.). Sure, WorkingSet is nice, it's the name used in setuptools, A WorkingSet and a DistributionDirectories (or whatever it gets named to) are different things though, no? A WorkingSet is "a collection of active distributions", where each distribution might come from different distribution directories: http://peak.telecommunity.com/DevCenter/PkgResources#workingset-objects Where as DistributionDirectories is a dictionary of locations where distributions are installed. The WorkingSet may be comprised of distributions from several different locations, and each location may contain the same or different versions of the same distribution. (as far as I understand things ...) I can't really think of a better name for a dict of distribution locations ... but then I'm not averse to a pluralized class name. Overall though, I think PEP 376 is starting to look very good! ___ 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 syntax for units of measure
Hi! Has anyone added special syntax to allow writing numeric literals with physical units? So you can write 12m + 34cm, and would get 12.34m. My question is how would you modify the BNF the most sensible way to allow for this? The above example is simple, but think of 42 km/h. (For my purposes, modifying the BNF is perfectly reasonable, but if you can depict a good, and convenient!, way that would not result in modifying it, I'd like to hear it, too.) Thanks in advance for your input, -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
