Re: [Python-Dev] When to remove deprecated stuff
Terry Reedy wrote: > On 8/15/2013 8:29 AM, R. David Murray wrote: > > >A number of us (I don't know how many) have clearly been thinking about > >"Python 4" as the time when we remove cruft. This will not cause any > >backward compatibility issues for anyone who has paid heed to the > >deprecation warnings, but will for those who haven't. The question > >then becomes, is it better to "bundle" these removals into the > >Python 4 release, or do them incrementally? > > 4.0 will be at most 6 releases after the upcoming 3.4, which is 9 to > 12 years, which is 7 to 10 years after any regular 2.7 maintainance > ends. > > The deprecated unittest synonyms are documented as being removed in > 4.0 and that already defines 4.0 as a future cruft-removal release. > However, I would not want it defined as the only cruft-removal > release and used as a reason or excuse to suspend removals until > then. I would personally prefer to do little* removals > incrementally, as was done before the decision to put off 2.x > removals to 3.0. So I would have 4.0 be an 'extra' or 'bigger' cruft > removal release, but not the only one. > > * Removing one or two pure synonyms or little used features from a > module. The unittest synonym removal is not 'little' because there > are 13 synonyms and at least some were well used. > > >If we are going to do them incrementally we should make that decision > >soonish, so that we don't end up having a whole bunch happen at once > >and defeat the (theoretical) purpose of doing them incrementally. > > > >(I say theoretical because what is the purpose? To spread out the > >breakage pain over multiple releases, so that every release breaks > >something?) > > Little removals will usually break something, but not most things. > Yes, I think it better to upset a few people with each release than > lots of people all at once. I think enabling deprecation notices in > unittest is a great idea. Among other reasons, it should spread the > effect of bigger removals scheduled farther in the future over the > extended deprecation period. > > Most deprecation notices should provide an alternative. (There might > be an exception is for things that should not be done ;-). For > module removals, the alternative should be a legacy package on PyPI. Removing some cruft on each release can be very painful for users. Django's deprecation policy works like this: They deprecate something in version A.B. It still works normally in A.B+1, generates a (silenced) DeprecationWarning in A.B+2, and is finally removed in A.B+3. So if I haven't read through the full release notes of each release nor enabled DeprecationWarnings, I end up having something broken each time I upgrade Django. I hope the same will not start happening each time I upgrade Python. When the removals happen on major version boundaries, it should be more evident that something will break. Then people can enable DepreationWarnings and test all the affected code thoroughly with the new version before upgrading. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to remove deprecated stuff
R. David Murray wrote: > > So you're still using features deprecated three releases ago, you haven't > > checked for DeprecationWarnings and it's Django making your life difficult? > > > > Why not check for the deprecation warnings? > > Doing so makes very little difference. > > This is my opinion (others obviously differ): > > Putting in one big chunk of effort at a major release boundary is easier > to schedule than putting in a chunk of effort on *every* feature > release. More importantly, having it happen only at the major release > boundary means there's only one hard deadline every ten-ish years, rather > than a hard deadline every 1.5 years. > > Expecting things to break when you switch to the new feature release > makes one view feature releases with dread rather than excitement. > > This applies whether or not one is testing with deprecation warnings on. > Yes, there's a little less pressure if you are making the fixes on > the deprecation release boundary, because you can always ship the > code anyway if it is winds up being too big of a bear, so you have more > scheduling flexibility. But you still face the *psychological* hurdle of > "feature release upgrade...will need to fix the all the things they've > deprecated...let's put that off". Especially since what we are talking > about here is the *big* cruft, and thus more likely to be a pain to fix. These are my thoughts exactly. Maybe I exaggerated a bit about Django. I was slightly unaware of the deprecation policy when Django 1.3 came out (IIRC it was the first release that actually removed deprecated stuff after 1.0). Nowadays I read release notes carefully and do what's needed, and nothing has broken badly ever since. What's really bothering me is that I have to change something in my code every time I upgrade Django. So as David said, it's more like "sigh, a new feature release again" than "yay, new cool features!". Or actually, it's a combination of both because I really want the new features. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl
Terry Reedy wrote: > On 5/24/2011 12:06 PM, Victor Stinner wrote: > >Le mardi 24 mai 2011 à 11:27 -0400, Terry Reedy a écrit : > >>> > >>>+.. function:: RAND_bytes(num) > >>>+ > >>>+ Returns *num* cryptographically strong pseudo-random bytes. > >>>+ > >>>+ .. versionadded:: 3.3 > >>>+ > >>>+.. function:: RAND_pseudo_bytes(num) > >>>+ > >>>+ Returns (bytes, is_cryptographic): bytes are *num* pseudo-random bytes, > >>>+ is_cryptographic is True if the bytes generated are cryptographically > >>>+ strong. > >>>+ > >>>+ .. versionadded:: 3.3 > >> > >>I am curious what 'cryptographically strong' means, what the real > >>difference is between the above two functions, and how these do not > >>duplicate what is in random.random. > > > >An important feature of a CPRNG (cryptographic pseudo-random number > >generator) is that even if you know all of its output, you cannot > >rebuild its internal state to guess next (or maybe previous number). The > >CPRNG can for example hash its output using SHA-1: you will have to > >"break" the SHA-1 hash (maybe using "salt"). > > So it is presumably slower. I still do not get RAND_pseudo_bytes, > which somehow decides internally what to do. According to the RAND_bytes manual page from OpenSSL: RAND_bytes() puts num cryptographically strong pseudo-random bytes into buf. An error occurs if the PRNG has not been seeded with enough randomness to ensure an unpredictable byte sequence. RAND_pseudo_bytes() puts num pseudo-random bytes into buf. Pseudo-random byte sequences generated by RAND_pseudo_bytes() will be unique if they are of sufficient length, but are not necessarily unpredictable. They can be used for non-cryptographic purposes and for certain purposes in cryptographic protocols, but usually not for key generation etc. And: RAND_bytes() returns 1 on success, 0 otherwise. The error code can be obtained by ERR_get_error(3). RAND_pseudo_bytes() returns 1 if the bytes generated are cryptographically strong, 0 otherwise. Both functions return -1 if they are not supported by the current RAND method. So it seems to me that RAND_bytes() either returns cryptographically strong data or fails (is it possible to detect the failure with the Python function? Should this be documented?). RAND_pseudo_bytes() always succeeds but does not necessarily generate cryptographically strong data. > > > Another important feature is that even if you know the internal state, > >you will not be able to guess all previous and next numbers, because the > >internal state is regulary updated using an external source of entropy. > >Use RAND_add() to do that explicitly. > > > >We may add a link to Wikipedia: > >http://en.wikipedia.org/wiki/CPRNG > > That would be helpful > > > >Read the "Requirements" section, it's maybe more correct than my > >explanation: > >http://en.wikipedia.org/wiki/CPRNG#Requirements > > > >About the random module, it must not be used to generate passwords or > >certificates, because it is easy to rebuild the internal state of a > >Mersenne Twister generator if you know the previous 624 numbers. Since > >you know the state, it's also easy to generate all next numbers. Seed a > >Mersenne Twister PRNG doesn't help. See my Hasard project if you would > >like to learn more about PRNG ;-) > > > >We may also add a link from random to SSL.RAND_bytes() and > >SSL.RAND_pseudo_bytes(). Obviously, the user needs to be familiar with the concept of "cryptographically strong randomness" to use these functions. Petri Lehtinen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl
Victor Stinner wrote: > I already patched the doc of the random module to add a security > warning. Well, you don't really need to know how a CSPRNG is > implemented, just that random cannot be used for security and that > ssl.RAND_bytes() raises an error if was seeded with enough data. > > Tell me if my warning is not clear: > > .. warning:: > >The generators of the :mod:`random` module should not be used for >security purposes, they are not cryptographic. Use ssl.RAND_bytes() >if you require a cryptographically secure pseudorandom number >generator. Looks good to me. Regarding style, you should probably make a link, like :func:`ssl.RAND_bytes()`. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl
Eric Smith wrote: > > Victor Stinner wrote: > >> I already patched the doc of the random module to add a security > >> warning. Well, you don't really need to know how a CSPRNG is > >> implemented, just that random cannot be used for security and that > >> ssl.RAND_bytes() raises an error if was seeded with enough data. > >> > >> Tell me if my warning is not clear: > >> > >> .. warning:: > >> > >>The generators of the :mod:`random` module should not be used for > >>security purposes, they are not cryptographic. Use ssl.RAND_bytes() > >>if you require a cryptographically secure pseudorandom number > >>generator. > > > > Looks good to me. Regarding style, you should probably make a link, > > like :func:`ssl.RAND_bytes()`. > > Does "are not cryptographic" have any meaning? (I'm not an expert, just > not sure). Should it not be "cryptographically secure", to match the next > sentence? Or just remove ", they are not cryptographic" altogether? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extending os.chown() to accept user/group names
Victor Stinner wrote: > Le mercredi 25 mai 2011 à 18:46 +0200, Charles-François Natali a écrit : > > While we're at it, adding a "recursive" argument to this shutil.chown > > could also be useful. > > I don't like the idea of a recursive flag. I would prefer a "map-like" > function to "apply" a function on all files of a directory. Something > like shutil.apply_recursive(shutil.chown)... FWIW, the chown program (in GNU coreutils at least) has a -R flag for recursive operation, and I've found it *extremely* useful on many situations. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extending os.chown() to accept user/group names
Nick Coghlan wrote: > 2011/5/26 Charles-François Natali : > > Then, I wonder why shutil.copytree and shutil.rmtree are provided. > > Recursive rm/copy/chown/chmod are extremely useful in system > > administration scripts. Furthermore, it's not as simple as it seems > > because of symlinks, see for example http://bugs.python.org/issue4489 > > Rather than a fixed binary flag, I would suggest following the > precedent of copytree and rmtree, and provide recursive functionality > as a separate shutil function (i.e. shutil.chmodtree, > shutil.chowntree). +1 > As noted, while these *can* be written manually, it is convenient to > have the logic for handling symlinks dealt with for you, as well as > not having to look up the particular incantation for correctly linking > os.walk and the relevant operations. This is exactly what I meant when saying that the -R option to chown and chmod shell commands is useful. I *could* do it without them, but writing the same logic every time with error handling would be cumbersome. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3101 implementation vs. documentation
Nick Coghlan wrote:
[snip]
> The rules for name fields would then become:
>
> 1. Numeric fields start with a digit and are terminated by any
> non-numeric character.
>
> 2. An identifier name field is terminated by any one of:
> '}' (terminates the replacement field)
> '!' (terminates identifier field, starts conversion specifier)
> ':' (terminates identifier field, starts format specifier)
> '.' (terminates identifier field, starts new identifier field for
> subattribute)
> '[' (terminates identifier field, starts index field)
>
> 3. An index field is terminated by ']' (subsequent character will
> determine next field)
+1
> That second set of rules is *far* more in line with the behaviour of
> the rest of the language than the status quo, so unless the difficulty
> of making the str.format mini-language parser work that way is truly
> prohibitive, it certainly seems worthwhile to tidy up the semantics.
>
> The index field behaviour should definitely be fixed, as it poses no
> backwards compatibility concerns. The brace matching behaviour should
> probably be left alone, as changing it would potentially break
> currently valid format strings (e.g. "{a{0}}".format(**{'a{0}':1})
> produces '1' now, but would raise an exception if the brace matching
> rules were changed).
-1 for leaving the brace matching behavior alone, as it's very
unintuitive for *the user*. For the implementor it may make sense to
count matching braces, but definitely not for the user. I don't
believe that "{a{0}}" is a real use case that someone might already
use, as it's a hard violation of what the documentation currently
says.
I'd rather disallow braces in the replacement field before the format
specifier altogether. Or closing braces at the minimum. Furthermore,
the double-escaping sounds reasonable in the format specifier, but not
elsewhere.
My motivation is that the user should be able to have a quick glance
on the format string and see where the replacement fields are. This is
probably what the PEP intends to say when disallowing braces inside
the replacement field. In my opinion, it's easy to write the parser in
a way that braces are parsed in any imaginable manner. Or maybe not
easy, but not harder than any other way of handling braces.
> So +1 on making the str.format parser accept anything other than ']'
> inside an index field and turn the whole thing into an ordinary
> string, -1 on making any other changes to the brace-matching
> behaviour.
>
> That would leave us with the following set of rules for name fields:
>
> 1. Numeric fields start with a digit and are terminated by any
> non-numeric character.
>
> 2. An identifier name field is terminated by any one of:
> '}' (terminates the replacement field, unless preceded by a
> matching '{' character, in which case it is ignored and included in
> the string)
> '!' (terminates identifier field, starts conversion specifier)
> ':' (terminates identifier field, starts format specifier)
> '.' (terminates identifier field, starts new identifier field for
> subattribute)
> '[' (terminates identifier field, starts index field)
>
> 3. An index field is terminated by ']' (subsequent character will
> determine next field)
>
> Note that brace-escaping currently doesn't work inside name fields, so
> that should also be fixed:
>
> >>> "{0[{{]}".format({'{':1})
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: unmatched '{' in format
> >>> "{a{{}".format(**{'a{':1})
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: unmatched '{' in format
-1. Why do we need braces inside replacement fields at all (except for
inner replacements in the format specier)? I strongly believe that the
PEP's use case is the simple one:
'{foo}'.format(foo=10)
In my opinoin, these '{!#%}'.format(**{'!#%': 10}) cases are not real.
The current documentation requires field_name to be a valid
identifier, an this is a sane requirement. The only problem is that
parsing identifiers correctly is very hard, so it can be made simpler
by allowing some non-identifiers. But we still don't have to accept
braces.
---
As a somewhat another issue, I'm confused about this:
>>> '{a[1][2]}'.format(a={1:{2:3}})
'3'
and even more about this:
>>> '{a[1].foo[2]}'.format(a={1:namedtuple('x', 'foo')({2:3})})
'3'
Why does this work? It's against the current documentation. The
documented syntax only allows zero or one attribute names and zero or
one element index, in this order. Is it intentional that we allow
arbitrary chains of getattr and __getitem__? If we do, this should be
documented, too.
Petri
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] is sys.modules not meant to be replaced?
Eric Snow wrote: > p.s. I tried opening a tracker ticket on this, but it wouldn't go > through. I'll try again later. Adding the following line to /etc/hosts makes the bug tracker fast when python.org is down: 127.0.0.1 python.org This is because bugs.python.org works fine, but it links to CSS files and images that are on python.org. Forcing DNS lookups for python.org to return localhost makes the requests for these resources fail fast. A more long-term solution would be to duplicate all the resources to bugs.python.org... Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Mirroring Python repos to Bitbucket
Doug Hellmann wrote: > > Charles McLaughlin of Atlassian has set up mirrors of the Mercurial > repositories hosted on python.org as part of the ongoing > infrastructure improvement work. These mirrors will give us a public > fail-over repository in the event that hg.python.org goes offline > unexpectedly, and also provide features such as RSS feeds of changes > for users interested in monitoring the repository passively. As a side note, for those preferring git there's also a very unofficial git mirror at https://github.com/jonashaag/cpython. It uses hg-git for converting and syncs once a day. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] counterintuitive behavior (bug?) in Counter with +=
Lars Buitinck wrote: > >>> from collections import Counter > >>> a = Counter([1,2,3]) > >>> b = a > >>> a += Counter([3,4,5]) > >>> a is b > False > > would become > > # snip > >>> a is b > True Sounds like a good idea to me. You should open an issue in the tracker at http://bugs.python.org/. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): Whoops, PyException_GetTraceback() is not documented on 2.7
Georg Brandl wrote: > On 10/23/11 20:54, petri.lehtinen wrote: > > http://hg.python.org/cpython/rev/5c4781a237ef > > changeset: 73073:5c4781a237ef > > branch: 2.7 > > parent: 73071:11da12600f5b > > user:Petri Lehtinen > > date:Sun Oct 23 21:52:10 2011 +0300 > > summary: > > Whoops, PyException_GetTraceback() is not documented on 2.7 > > If it exists there, why not document it instead? :) Hmm, an interesting idea. I'll see what I can do :) Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): Whoops, PyException_GetTraceback() is not documented on 2.7
Petri Lehtinen wrote: > Georg Brandl wrote: > > On 10/23/11 20:54, petri.lehtinen wrote: > > > http://hg.python.org/cpython/rev/5c4781a237ef > > > changeset: 73073:5c4781a237ef > > > branch: 2.7 > > > parent: 73071:11da12600f5b > > > user:Petri Lehtinen > > > date:Sun Oct 23 21:52:10 2011 +0300 > > > summary: > > > Whoops, PyException_GetTraceback() is not documented on 2.7 > > > > If it exists there, why not document it instead? :) > > Hmm, an interesting idea. I'll see what I can do :) It seems it doesn't exist on 2.7 after all. I just failed with my hg-fu and thought it was there. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: #13251: update string description in datamodel.rst.
Hi, ezio.melotti wrote: > http://hg.python.org/cpython/rev/11d18ebb2dd1 > changeset: 73116:11d18ebb2dd1 > user:Ezio Melotti > date:Tue Oct 25 09:23:42 2011 +0300 > summary: > #13251: update string description in datamodel.rst. > > files: > Doc/reference/datamodel.rst | 20 ++-- > 1 files changed, 10 insertions(+), 10 deletions(-) > > > diff --git a/Doc/reference/datamodel.rst b/Doc/reference/datamodel.rst > --- a/Doc/reference/datamodel.rst > +++ b/Doc/reference/datamodel.rst > @@ -276,16 +276,16 @@ > single: integer > single: Unicode > > - The items of a string object are Unicode code units. A Unicode code > - unit is represented by a string object of one item and can hold > either > - a 16-bit or 32-bit value representing a Unicode ordinal (the maximum > - value for the ordinal is given in ``sys.maxunicode``, and depends on > - how Python is configured at compile time). Surrogate pairs may be > - present in the Unicode object, and will be reported as two separate > - items. The built-in functions :func:`chr` and :func:`ord` convert > - between code units and nonnegative integers representing the Unicode > - ordinals as defined in the Unicode Standard 3.0. Conversion from > and to > - other encodings are possible through the string method > :meth:`encode`. > + A string is a sequence of values that represent Unicode codepoints. > + All the codepoints in range ``U+ - U+10`` can be represented > + in a string. Python doesn't have a :c:type:`chr` type, and > + every characters in the string is represented as a string object typo ^ Should be "character", right? > + with length ``1``. The built-in function :func:`chr` converts a > + character to its codepoint (as an integer); :func:`ord` converts > + an integer in range ``0 - 10`` to the corresponding character. Actually chr() converts an integer to a string and ord() converts a string to an integer. chr and ord are swapped in your text. > + :meth:`str.encode` can be used to convert a :class:`str` to > + :class:`bytes` using the given encoding, and :meth:`bytes.decode` > can > + be used to achieve the opposite. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #13226: Add RTLD_xxx constants to the os module. These constants can by
Hi, victor.stinner wrote: > http://hg.python.org/cpython/rev/c75427c0da06 > changeset: 73127:c75427c0da06 > user:Victor Stinner > date:Tue Oct 25 13:34:04 2011 +0200 > summary: > Issue #13226: Add RTLD_xxx constants to the os module. These constants can > by > used with sys.setdlopenflags(). > > files: > Doc/library/os.rst | 13 + > Doc/library/sys.rst| 10 +- > Lib/test/test_posix.py | 7 +++ > Misc/NEWS | 3 +++ > Modules/posixmodule.c | 26 ++ > 5 files changed, 54 insertions(+), 5 deletions(-) [snip] > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -341,6 +341,9 @@ > Library > --- > > +- Issue #13226: Add RTLD_xxx constants to the os module. These constants can > by Typo: s/by/be/ > + used with sys.setdlopenflags(). > + > - Issue #10278: Add clock_getres(), clock_gettime() and CLOCK_xxx constants > to >the time module. time.clock_gettime(time.CLOCK_MONOTONIC) provides a >monotonic clock Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] None as slice params to list.index() and tuple.index()
list.index() and list.tuple() don't currently accept None as slice parameters, as reported in http://bugs.python.org/issue13340. For example: >>> [1, 2, 3].index(2, None, None) Traceback (most recent call last): File "", line 1, in TypeError: slice indices must be integers or None or have an __index__ method The error message of list.index() and tuple.index() (as a consequence of using _PyEval_SliceIndex() for parsing arguments) indicates that None is a valid value. Currently, find(), rfind(), index(), rindex(), count(), startswith() and endswith() of str, bytes and bytearray accept None. Should list.index() and tuple.index() accept it, too? I'm bringing this up because I already committed a fix that enables the None arguments, but Raymond pointed out that maybe they shouldn't accept None at all. I also committed the fix to 3.2 and 2.7 based on discussion in http://bugs.python.org/issue11828#msg133532, in which Raymond says that for string functions, this can be considered a bug because the exception's error message makes a promise that None is accepted. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
Terry Reedy wrote: > On 11/8/2011 10:49 AM, Jesus Cea wrote: > >-BEGIN PGP SIGNED MESSAGE- > >Hash: SHA1 > > > >When merging from 3.2 to 3.3 "Misc/NEWS" always conflicts (lately). > >Instead of copy&paste the test manually between versions, has anybody > >a better workflow?. > > If a bug is fixed in 3.2.latest, then it will not be new in 3.3.0, > so perhaps it should not be added there. NEWS could just refer back > to previous sections. Then 3.3.0 News would only be new features and > the occasional ambiguous item not fixed before. In this case, we would have to *remove* entries from Misc/NEWS after merging to 3.3, right? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch metadata - to use or not to use?
Nick Coghlan wrote: > Generally speaking, it's more useful for the checkin metadata to > reflect who actually did the checkin, since that's the most useful > information for the tracker and buildbot integration. At least in git, the commit metadata contains both author and committer (at least if they differ). Maybe mercurial has this too? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"
Jesus Cea wrote: > On 12/11/11 16:56, Éric Araujo wrote: > > Ezio and I chatted a bit about his on IRC and he may try to write > > a Python parser for Misc/NEWS in order to write a fully automated > > merge tool. > > Anything new in this front? :-) I don't see what's the problem really. The most common case is to have one conflicting file with one conflict. I'm completely fine with removing the conflict markers and possibly moving my own entry above the other entries. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
Raymond Hettinger wrote: > How about we agree that actually removing things is usually bad for users. > It will be best if the core devs had a strong aversion to removal. > Instead, it is best to mark APIs as obsolete with a recommendation to use > something else instead. > > There is rarely a need to actually remove support for something in > the standard library. > > That may serve a notion of tidyness or somesuch but in reality it is > a PITA for users making it more difficult to upgrade python versions > and making it more difficult to use published recipes. I'm strongly against breaking backwards compatiblity between minor versions (e.g. 3.2 and 3.3). If something is removed in this manner, the transition period should at least be very, very long. To me, deprecating an API means "this code will not get new features and possibly not even (big) fixes". It's important for the long term health of a project to be able to deprecate and eventually remove code that is no longer maintained. So, I think we should have a clear and working deprecation policy, and Ezio's suggestion sounds good to me. There should be a clean way to state, in both code and documentation, that something is deprecated, do not use in new code. Furthermore, deprecated code should actually be removed when the time comes, be it Python 4.0 or something else. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
Michael Foord wrote: > We tend to see 3.2 -> 3.3 as a "major version" increment, but that's > just Python's terminology. Even though (in the documentation) Python's version number components are called major, minor, micro, releaselevel and serial, in this order? So when the minor version component is increased it's a major version increment? :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Long term development external named branches and periodic merges from python
Nick Coghlan wrote: > > So, in this context, if the tracker "create patch" diff from BASE, it > > is not "safe" to merge changes from mainline to the branch, because if > > so "create patch" would include code not related to my work. > > No, "Create Patch" is smarter than that. What it does (or tries to do) > is walk back through your branch history, trying to find the last > point where you merged in a changeset that it recognises as coming > from the main CPython repo. It then uses that revision of the CPython > repo as the basis for the diff. > > So if you're just working on a feature branch, periodically pulling > from hg.python.org/cpython and merging from default, then it should > all work fine. > > Branches-of-branches (i.e. where you've merged from CPython via > another named branch in your local repo) seems to confuse it though - > I plan to change my workflow for those cases to merge each branch from > the same version of default before merging from the other branch. The ancestor() revset could help for the confusion: http://stackoverflow.com/a/6744163/639276 In this case, the user would have to be able to tell the branch against which he wants the diff. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.format implementation
Ben Wolfson wrote:
> Hi,
>
> I'm hoping to get some kind of consensus about the divergences between
> the implementation and documentation of str.format
> (http://mail.python.org/pipermail/python-dev/2011-June/111860.html and
> the linked bug report contain examples of the divergences). These
> pertain to the arg_name, attribute_name, and element_index fields of
> the grammar in the docs:
>
> replacement_field ::= "{" [field_name] ["!" conversion] [":"
> format_spec] "}"
> field_name::= arg_name ("." attribute_name | "["
> element_index "]")*
> arg_name ::= [identifier | integer]
> attribute_name::= identifier
> element_index ::= integer | index_string
> index_string ::= +
>
> Nothing definitive emerged from the last round of discussion, and as
> far as I can recall there are now three proposals for what kind of
> changes might be worth making:
>
> (1) the implementation should conform to the docs;*
> (2) like (1) with the change that element_index should be changed to
> "integer | identifier" (rendering index_string otiose);
> (3) like (1) with the change that index_string should be changed to
> ''.
>
> * the docs link "integer" to
> http://docs.python.org/reference/lexical_analysis.html#grammar-token-integer
> but the current implementation only allows decimal integers, which
> seems reasonable and worth retaining.
>
> (2) was suggested by Greg Ewing on python-dev and (3) by Petri
> Lehtinen in the bug report. (Petri actually suggested that braces be
> disallowed except for the nesting in the format_spec, but it comes to
> the same thing.)
>
> None of these should be difficult to implement; patches exist for (1)
> and (2). (2) and (3) would lead to format strings that are easier to
> for the programmer to visually parse; (1) would make the indexing part
> of the replacement field conform more closely to the way indexing with
> strings behaves in Python generally, where arbitrary strings can be
> used. (It wouldn't conform exactly, obviously, since ']' would still
> be excluded.)
>
> I personally would prefer (1) to (2) or (3), and (3) to (2), had I my
> druthers, but it doesn't matter a *whole* lot to me; I'd prefer any of
> them to nothing (or to changing the docs to reflect the current batty
> behavior).
+1 for changing. And as I've said before, I prefer proposal (3).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling the source without stat
Hossein wrote: > Hi. I just started to port latest python 2.7.2 to another platform > (don't think you're eager to know... well it's CASIO ClassPad). > And I faced a "minor" problem... It hasn't got stat or fstat or > anything. (It supports a very limited set of c std lib). > As pyport.c suggested, i defined both DONT_HAVE_STAT and > DONT_HAVE_FSTAT, but problems only began. > It failed to compile most of import.c, particularly because it fell > into the wrong `#if !defined(PYOS_Something)' blocks. Sometimes it > just fell into an #else part which assumed stat are available. So > although HAVE_STAT is meant to control file operations, most of the > source code aren't implement to use it. You see how "minor" the > problem was? > So now I need advice from developers. > Is there a fix for it? What a question... definitely no replacement to stat. > It's 99% definite that I can't compile further without touching the > source code. I have to #define my own PYOS_whatever and handle files > in my own way. In that case where should my special file handling > cases go? I saw some marshal.c code which seemed it wants to > abstract away platform's file handling from source code; but from > what I understood it can't be made to use alternate file handling > methods. > If there is anything I should do (maybe show you my handmade > pyconfig.h?) tell me. See http://bugs.python.org/issue12082. Currently neither Python 2.x nor 3.x can be compiled without stat() or fstat(). Python 2.7 almost compiles, but Python 3 depends heavily on them. The problem boils down to the fact that you cannot really check whether a filesystem entry is a directory without calling stat() or fstat(). My personal opinion is that support for DONT_HAVE_STAT and DONT_HAVE_FSTAT defines should be dropped because they don't work, and would only be useful in a very limited set of cases. > [My first post in a mailing list... Should I say] Best Regards, n> Hossein [in here?] Yeah, why not? :) Regards, Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
Antoine Pitrou wrote:
> I don't like having the else on the same line as the closing brace,
> and prefer:
>
>if (cond) {
>statement;
>}
>else {
>statement;
>}
And this is how it's written in PEP-7. It seems to me that PEP-7
doesn't require braces. But it explicitly forbids
if (cond) {
statement;
} else {
statement;
}
by saying "braces as shown", and then showing them like this:
if (mro != NULL) {
...
}
else {
...
}
> That said, I agree with Benjamin: the shorter form is visually lighter
> and should not be frown upon.
Me too.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): #9559: Append data to single-file mailbox files if messages are only added
Antoine Pitrou wrote: > > If messages were only added, a new file is no longer created and > > renamed over the old file when flush() is called on an mbox, MMDF or > > Babyl mailbox. > > Why so? Appending is not atomic and, if it fails in the middle, you > could get a corrupt mbox file. > Furthermore, I disagree that it's a bugfix: IMO it should wait for 3.4. The code previosly already appended messages to the end of the file when calling add(). This patch just changed it to not do a full rewrite when flush() is called. Having a partially written message in the end of your mailbox doesn't seem like a fatal corruption to me. Furthermore, I (and R. David Murray) think this is not so surprising for users. Most (or all) other implementations always write changes in-place without renaming, as this makes it possible to find out whether new mail has arrived. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): #9559: Append data to single-file mailbox files if messages are only added
R. David Murray wrote: > It is true, however, that Petri found that mutt (I think?) does some extra > gymnastics to provide recovery where the write fails part way through, > and it would be worth adding that as an enhanced bugfix if someone > has the motivation (basically, make a copy of the unmodified mailbox > and mv it back into place if the write fails). This is not what mutt does. It just writes the modified part of the mailbox to a temporary file, and then copies the data from the temporary file to the mailbox file. If this last step fails, the temporary file is left behind for recovery. Copying the whole mailbox before making modifications might be clever, though. It's just quite a lot of writing, especially for big mailboxes. OTOH, the whole file is rewritten by the current code, too. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GitHub mirror (Was: Bitbucket mirror?)
anatoly techtonik wrote: > On the subject. Is there a mirror of CPython on GitHub? https://github.com/akheron/cpython > changes to repository (and allows anonymous to do this). I've made > more than a dozen proposal for fixing docs, because as a matter of > fact - filling a bug AND explaining why docs are wrong, why they need > to be fixed, what should be added - all of this is a way *much easier* > (and less time consuming!) than just fixing them. Unfortunately. You won't get any changes in to CPython by creating pull requests. We use http://bugs.python.org/ for that, sorry. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug in tarfile module?
Chris Withers wrote:
> Hi All,
>
> This feels like a bug, but just wanted to check here before filing a
> report if I've missed something:
>
> buzzkill$ python2.7
> Enthought Python Distribution -- www.enthought.com
> Version: 7.2-2 (32-bit)
>
> Python 2.7.2 |EPD 7.2-2 (32-bit)| (default, Sep 7 2011, 09:16:50)
> [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
> Type "packages", "demo" or "enthought" for more information.
> >>> import tarfile
> >>> source = open('/src/Python-2.6.7.tgz', 'rb')
> >>> tar = tarfile.open(fileobj=source, mode='r|*')
> >>> member = tar.extractfile('Python-2.6.7/Lib/genericpath.py')
> >>> data = member.read()
> Traceback (most recent call last):
> File "", line 1, in
> File
> "/Library/Frameworks/Python.framework/Versions/7.2/lib/python2.7/tarfile.py",
> line 815, in read
> buf += self.fileobj.read()
> File
> "/Library/Frameworks/Python.framework/Versions/7.2/lib/python2.7/tarfile.py",
> line 735, in read
> return self.readnormal(size)
> File
> "/Library/Frameworks/Python.framework/Versions/7.2/lib/python2.7/tarfile.py",
> line 742, in readnormal
> self.fileobj.seek(self.offset + self.position)
> File
> "/Library/Frameworks/Python.framework/Versions/7.2/lib/python2.7/tarfile.py",
> line 554, in seek
> raise StreamError("seeking backwards is not allowed")
> tarfile.StreamError: seeking backwards is not allowed
>
> The key is the "mode='r*|" which I understood to be specifically for
> reading blocks from a stream without seeking that would cause
> problems.
When discussing "filemode|[compression]" modes, the docs say:
However, such a TarFile object is limited in that it does not
allow to be accessed randomly
I'm not a tarfile expert, but extracting a single file sounds like
random access to me. If it was the first file in the archive (or there
was only one file) it probably wouldn't count as random access.
Petri
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
Daniel Holth wrote: > I don't know of a tool that doesn't reliably ignore extra fields, but > I will put you down as being in favor of an X- fields paragraph: > > Extensions (X- Fields) > :: > > Metadata files can contain fields that are not part of > the specification, called *extensions*. These fields start with > with `X-`. See RFC 6648 for why such X-fields may not be a good idea: http://tools.ietf.org/html/rfc6648 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question re: default branch and release clone
Georg Brandl wrote: > Changes to the default branch must be bugfix-only. The 3.4 development > only opens when the 3.3 branch is created, which happens after the > release of 3.3.0 final. > > Changes made in default and not cherry-picked to the 3.3.0 release clone > will therefore end up in 3.3.1 and 3.4. Where should I put the news entry for fixes that will go to 3.3.1? The top item in Misc/NEWS is 3.3.0 RC 2. The stuff in your private clone will be released as 3.3.0, so can a 3.3.1 entry be added to the default branch of the public repo now? And if changes like this are added now, they will be included in 3.2.4 but not in 3.3.0. Is this bad? Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default): merge 3.2 (#15801)
Hi, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/263d09ce3e9e > changeset: 78794:263d09ce3e9e > parent: 78790:454dceb5fd56 > parent: 78793:4d431e719646 > user:Benjamin Peterson > date:Tue Aug 28 18:01:45 2012 -0400 > summary: > merge 3.2 (#15801) > > files: > Lib/test/string_tests.py | 3 +++ > Misc/NEWS| 3 +++ > Objects/unicodeobject.c | 3 +-- > 3 files changed, 7 insertions(+), 2 deletions(-) > [snip] > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -71,6 +71,9 @@ > > - Issue #15761: Fix crash when PYTHONEXECUTABLE is set on Mac OS X. > > +- Issue #15801: Make sure mappings passed to '%' formatting are actually > + subscriptable. > + > - Issue #15726: Fix incorrect bounds checking in PyState_FindModule. >Patch by Robin Schreiber. The news entry was added in the middle of the news for 3.3.0 RC 1, which has already been released. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failed issue tracker submission
Python tracker wrote:
>
>
> The node specified by the designator in the subject of your message
> ("715365") does not exist.
>
> Subject was: "[issue715365]"
Is this related to the Coverity ID being mentioned in
http://bugs.python.org/issue15868 ?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Bug Day in October
Éric Araujo wrote: > Hi all, > > The Montreal-Python user group would like to host a bug day on October > 27 (to be confirmed) at a partner university in Montreal. It would be > cool to do a bug day on IRC like we used to (and in other physical > locations if people want to!) to get new contributors and close bugs. > What do you think? Sounds good to me. I'm currently gathering a list [1] of easy and easyish issues for the PyCon Finland sprint, because finding things to work on is (in my opinion) the hardest and most time consuming part of bug fixing. I'm going to organize the list in the same way the stdlib documentation [2] is split into sections, so there should be something to work on for everyone, regardless of their interest area. PyCon Finland is on October 22-23, and I expect most of the list remain unused, so maybe it could also be used in the bug day afterwards. What do you think? Petri [1] http://piratepad.net/pyconfi-sprint-issues [2] http://docs.python.org/dev/library/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Bug Day in October
Éric Araujo wrote: > Hi Chris, > > Le 02/10/2012 18:14, Chris Angelico a écrit : > > Apologies if this is a stupid question (or just completely > > misdirected), but does this mean that if I'm interested in > > participating in the bug day, the first step should be to join > > core-mentorship@? > > It’s not required, but you are welcome to do it. I’ll send an > announcement with details about participating soon™. It's two and a half weeks left, but I've not seen any announcements yet! Also, my issue list at http://piratepad.net/pyconfi-sprint-issues still lacks entries, so everyone interested in making the bug day a huge success is welcome to add issues to the list. It doesn't need registration or anything, just open it in your browser and edit. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
Trent Nelson wrote: > > build breaking is another matter, of course. If we are > > going to mandate a specific version again, that should be documented and > > checked for. > > My preference: bump to 2.69 and set AC_PREREQ(2.69). If 2.69 proves > unworkable, revert back to 2.68 and AC_PREREQ(2.68). > > I definitely like the idea of explicitly setting the version being > used via AC_PREREQ, as this will prevent accidental version churn > being checked in by a committer inadvertently. Bear in mind that AC_PREREQ sets the minimum required version. It cannot be used to prevent from running newer autoconf in the future. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Bug Day this Saturday announced
Éric Araujo wrote: > The list by Petri at http://piratepad.net/pyconfi-sprint-issues can > still be updated. Otherwise we’ll fall back to the usual roundup query > for easy bugs. I've removed the issues for which a patch was submitted during the PyCon Finland sprint, and retitled it as Python Bug Day issue list. People found the list somewhat useful during our sprint. At least it has some starting points to look at, before starting to dig through the easy issues list. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] problems building python2.7
Chris Withers wrote: > On 09/11/2012 10:52, Michael Foord wrote: > > > >>However, I can't find the python it's built... > > > >It should be python.exe (yes really). > > Hah! Should http://docs.python.org/devguide/ be updated to reflect > this or does this only affect Mac OS? (or should we correct the > build so it doesn't spit out a .exe?) The filesystem on Mac OS X is case-insensitive by default, so plain "python" would clash with the "Python" directory. > >After the build you should be able to do: > > > > ./python.exe > > Unfortunately, still: > > buzzkill:cpython chris$ ./python.exe -m test -j3 > /Users/chris/LocalHG/cpython/python.exe: No module named > test.__main__; 'test' is a package and cannot be directly executed > [18856 refs] You're running the tests for Python 2, so the corret way to do it is: ./python.exe -m test.regrtest See http://docs.python.org/devguide/runtests.html#running . ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
Brett Cannon wrote: > Do we have a graph of the historical trend of the number of bugs (or at least > the historical details stored somewhere)? I think we have had a net decrease > in > open bugs the last couple of weeks and it would be neat to see an absolute and > relative graph of the overall trend since Python 3.3.0 was released. Also > might > make a nice motivator to try to close issues faster. =) > > Otherwise is the code public for this somewhere? I assume it's making an > XML-RPC call or something every week to get the results, but if I decide to do > a little App Engine app to store historical data and do a graph I would rather > not have to figure all of this out from scratch. =) Although I could I guess > also parse the email if I wanted to ignore all other emails. A few months ago I made a script that downloads all python-dev mailman archives, scans them to find the summary messages, parses the messages and creates a graph using matplotlib. The script is available at https://gist.github.com/2723809. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Emacs users: hg-tools-grep
Brandon W Maister wrote: > (defconst git-tools-grep-command > "git ls-files -z | xargs -0 grep -In %s" > "The command used for grepping files using git. See `git-tools-grep'.") What's wrong with git grep? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Emacs users: hg-tools-grep
Ross Lagerwall wrote: > On Wed, Dec 12, 2012 at 01:27:21PM +0200, Petri Lehtinen wrote: > > Brandon W Maister wrote: > > > (defconst git-tools-grep-command > > > "git ls-files -z | xargs -0 grep -In %s" > > > "The command used for grepping files using git. See `git-tools-grep'.") > > > > What's wrong with git grep? > > Or "hg grep", for that matter? hg grep searches in the repository history, so it's not good for this. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
