Re: [Python-Dev] Mercurial migration: help needed
[Adjusted the CCs...] On 19/08/2009 8:21 AM, Dj Gilcrease wrote: On Tue, Aug 18, 2009 at 2:12 AM, "Martin v. Löwis" wrote: The second item is line conversion hooks. Dj Gilcrease has posted a solution which he considers a hack himself. Mark Hammond has also volunteered, but it seems some volunteer needs to be "in charge", keeping track of a proposed solution until everybody agrees that it is a good solution. It may be that two solutions are necessary: a short-term one, that operates as a hook and has limitations, and a long-term one, that improves the hook system of Mercurial to implement the proper functionality (which then might get shipped with Mercurial in a cross-platform manner). My solution is a hack because the hooks in Mercurial need to be modified to support it properly, I would be happy to help work on this as it is a situation I run into all the time in my own projects. I can never seem to get all the developers to enable the hooks, and one of them always commits with improper line endings =P Maybe you can enumerate what you think needs to change in mercurial, then once we have a plan in place it will be clearer who can do what. I'm resurrecting my patch to support a filter called 'none' (which is turning out to be harder than I thought). Off the top of my head, it would the following would give us a pretty solid solution: * Finish my patch for 'none' as a filter, so '**=cleverencode' can be reasonably used (currently you can't specify specific files *not* have cleverencode, making it unsuitable in practice without the concept of 'none') * Add support for versioned 'filter rules' - eg, /.hgfilters or similar. * This might be pushing my luck, but: add 'defensive' support to core hg for this feature - if /.hgfilters exists, hg should refuse to operate on the working tree unless the win32text extension is enabled. Note that this last point still leaves win32text optional for hg itself - but if the owner of a repository has explicitly 'opted in' for win32text support, hg can still assist in refusing to screw the tree. The hg user has the option of enabling that extension, declining to use that repository, or arguing with the owner of the repo about use of the feature in the first place. Is there something I'm missing? Or maybe a better way to have hg enforce a repository's policy while not inflicting pain on hg users who don't want to ever think about windows? Cheers, Mark ___ 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] Mercurial migration: help needed
On Fri, Aug 21, 2009 at 09:16, Mark Hammond wrote: > I'm resurrecting my patch to support a filter called 'none' (which is > turning out to be harder than I thought). Off the top of my head, it would > the following would give us a pretty solid solution: > > * Finish my patch for 'none' as a filter, so '**=cleverencode' can be > reasonably used (currently you can't specify specific files *not* have > cleverencode, making it unsuitable in practice without the concept of > 'none') > > * Add support for versioned 'filter rules' - eg, /.hgfilters or similar. > > * This might be pushing my luck, but: add 'defensive' support to core hg for > this feature - if /.hgfilters exists, hg should refuse to operate on the > working tree unless the win32text extension is enabled. Sounds great to me. The latter might indeed be hard to get into the core, but seems like a good idea to try. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
Mark Hammond writes: > * Add support for versioned 'filter rules' - eg, /.hgfilters or similar. > > * This might be pushing my luck, but: add 'defensive' support to core hg > for this feature - if /.hgfilters exists, hg should refuse to operate on > the working tree unless the win32text extension is enabled. The name ".hgfilters" should be changed, then. That's way too generic to be used to "enforce" something as specific as win32text. I can imagine all kinds of things wanting to use rules or filters. How about a scheme where an extension reserves a filter file for itself in .hgfilters? In this case the win32text filters would live in .hgfilters/win32text, and if that file exists hg checks that the corresponding extension has been enabled, and if not, refuses to run (and tells you that if you really want to override, you rename the file to win32text.disabled and commit). Note that Bazaar is currently discussing some similar policies. I think the name they have settled on is ".bzrrules". Maybe .hgrules is a better name. -- Q: What are those straight lines? A: "XEmacs rules." ___ 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] Mercurial migration: help needed
Stephen J. Turnbull wrote: > Note that Bazaar is currently discussing some similar policies. I > think the name they have settled on is ".bzrrules". Maybe .hgrules is > a better name. So it would be .hgrules/? With the extension then defining the contents of the rule file? An alternative would be to go one level deeper and have: .hgrules/required/ .hgrules/optional/ If an extension rule file appeared in the first subdirectory then hg would refuse to operate on the repository without that extension being enabled. I guess something like that might be nice to have, but the support for negative filtering and versioned rule definitions is all we really need from a python-dev point of view. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
Joel Bender wrote: > Nick Coghlan wrote: > >> Maybe this is something that differs by country, but I have *never* >> heard the first address in an IP network (i.e. every bit not covered by >> the netmask set to zero) referred to as anything other than the "network >> address". > > Ah! A change to interject a mostly pointless comment... > > Prior to IEN-212 [1] it wasn't standardized, the 'zero' was used and > supported by the Berkeley socket library. This was a number of years > ago, however (!), and I dare say the sample code is lost to antiquity. Ah, that would be me showing my (lack of) age then :) I was still six years or so away from getting my first computer and more than 15 years away from any formal networking training when that note was published... Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
http://ipaddr-py.googlecode.com/svn/branches/2.0.x/ipaddr.py > _compat_has_real_bytes = bytes != str Wouldn't it be nicer "bytes is not str"? Oleg. -- Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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 3144: IP Address Manipulation Library for the Python Standard Library
-On [20090820 20:19], Peter Moody (pe...@hda3.com) wrote: >I've updated the pep with lots of examples; most of the stuff you're >asking for is already supported, I just didn't do a good job >explaining it. A few things are pending review. Thanks for that Peter! -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Earth to earth, ashes to ashes, dust to dust... ___ 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] Mercurial migration: help needed
Nick Coghlan writes: > Stephen J. Turnbull wrote: > > Note that Bazaar is currently discussing some similar policies. I > > think the name they have settled on is ".bzrrules". Maybe .hgrules is > > a better name. > > So it would be .hgrules/? With the extension then > defining the contents of the rule file? Yes. > An alternative would be to go one level deeper and have: > > .hgrules/required/ > .hgrules/optional/ I thought briefly about that kind of thing. However, this way would require deciding the semantics of the subdirectories, and while "optional" vs "required" is pretty appealing, how about "required" vs. "requisite"? (As Dave Barry would say, "I am *still* not kidding." See: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html Of course anything related to Python would do a better job of naming, but such semantic fine points might very well be important. And yes, there are people who take their VCS as seriously as they take authenticating as root.) So what I thought was that extensions would provide a policy function, which would make such judgments when called. But then I realized I had no clue what the semantics should be, so I didn't mention it. ___ 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] Two laments about CPython's AST Nodes
On Thu, Aug 20, 2009 at 6:11 PM, "Martin v. Löwis" wrote: > Couldn't you just generate a check function for your tree that > would be invoked before you try to process a tree that a > script got access to? That would be one way, though now that I understand CPython's AST design better, I am tempted to follow the lead. If I had a private AST and and a public mirror for ast.py, the design could become much simpler, and probably faster for normal parsing. > If you are asking that a type check is made on assigning a value to > these fields - I'm not quite sure whether you could implement that > check reliably. Wouldn't it be possible to bypass it by filling a > value directly into __dict__? > > If you can come up with a patch that checks in a reliable manner, > I would be in favor of adding that (in 2.7 and 3.2), taking out > the corresponding checks when converting to the internal AST. Great, I may give it a try, but changing the AST impl for Jython 2.6 will probably be my short term answer. -Frank ___ 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] Mercurial migration: help needed
On Fri, Aug 21, 2009 at 1:16 AM, Mark Hammond wrote: > Maybe you can enumerate what you think needs to change in mercurial, then > once we have a plan in place it will be clearer who can do what. The encode/decode hooks need to be passed the filename they are working on so you can have an ignore list, this is why I consider my method a hack since I am using a precommit hook to do conversion since I am able to find out which file I am working on and make sure it is not in an ignore list. There also needs to be a way to have required and version controlled extensions. This weekend I plan on digging into Mercurials hook code and doing up a patch so the encode/decode hooks accept the filename they are working on in a backwards compatible way > An alternative would be to go one level deeper and have: > > .hgrules/required/ > .hgrules/optional/ I like this, though maybe .hgextensions since it would contain versioned rules and the actual required extension. The extra sub directories are not really required IMHO, you just have a hgrc file that works the same as the local hgrc file except it only looks in the .hgextensions directory for the correct extension so for python we could have something like [extensions] format_enforcer = [encode] **=format_enforcer.cleverencode [ignore] *.sln= ... [hooks] pretxncommit.crlf = python:format_enforcer.forbidcrlf pretxncommit.cr = python:format_enforcer.forbidcr ___ 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] Mercurial migration: help needed
On Fri, Aug 21, 2009 at 16:10, Dj Gilcrease wrote: > I like this, though maybe .hgextensions since it would contain > versioned rules and the actual required extension. The extra sub > directories are not really required IMHO, you just have a hgrc file > that works the same as the local hgrc file except it only looks in the > .hgextensions directory for the correct extension so for python we > could have something like > > [extensions] > format_enforcer = Enabling extensions in a versioned file is not going to fly. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
On Fri, Aug 21, 2009 at 8:19 AM, Dirkjan Ochtman wrote: > Enabling extensions in a versioned file is not going to fly. any specific reason? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (08/14/09 - 08/21/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2353 open (+40) / 16226 closed (+15) / 18579 total (+55) Open issues with patches: 928 Average duration of open issues: 656 days. Median duration of open issues: 411 days. Open Issues Breakdown open 2322 (+40) pending30 ( +0) Issues Created Or Reopened (57) ___ Allow buffering for HTTPResponse 08/18/09 CLOSED http://bugs.python.org/issue4879reopened r.david.murray patch, patch Py3.1 hangs in coroutine and eats up all memory 08/17/09 http://bugs.python.org/issue6673reopened scoder 64bit cross platform failure and silly test in doctest 08/14/09 http://bugs.python.org/issue6703created cjw296 better col_offset for AST in statements like "for a,b in ..."08/14/09 CLOSED http://bugs.python.org/issue6704created fwierzbicki patch '''3,5'''.strip(r''',''') does not strip comma, returns '3,5'08/14/09 CLOSED http://bugs.python.org/issue6705created mgruen asyncore's accept() is broken08/14/09 http://bugs.python.org/issue6706created giampaolo.rodola dir() on __new__'d module w/o dict crashes 2.6.2 08/14/09 CLOSED http://bugs.python.org/issue6707created DinoV raw_input() calls generate compile errors. 08/15/09 CLOSED http://bugs.python.org/issue6708created starz It's possible to create TryExcept with no handlers 08/15/09 http://bugs.python.org/issue6709created benjamin.peterson hotshot stats load causes TypeError when multiple files are load 08/15/09 http://bugs.python.org/issue6710created j1m macurl2path has typos that raise AttributeError 08/16/09 CLOSED http://bugs.python.org/issue6711created joe.amenta patch sys._getframe is not available on all Python implementations 08/16/09 http://bugs.python.org/issue6712created johannes.janssen Integer & Long types: Performance improvement of 1.6x to 2x for 08/16/09 http://bugs.python.org/issue6713created gawain memmove fails with unicode strings 08/16/09 CLOSED http://bugs.python.org/issue6714created verigak xz compressor support08/17/09 http://bugs.python.org/issue6715created devurandom Windows install error when choosing to compile .py files 08/17/09 http://bugs.python.org/issue6716created pds Some problem with recursion handling 08/17/09 http://bugs.python.org/issue6717created gregorlingl ValueError in 21.17.4.2. SocketServer.UDPServer Example 08/17/09 http://bugs.python.org/issue6718created ericpope pdb messes up when debugging an non-ascii program08/17/09 http://bugs.python.org/issue6719created smu
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
On Thu, Aug 20, 2009 at 10:15 PM, Case Vanhorsen wrote:
>>On Thu, Aug 20, 2009 at 2:00 PM, Peter Moody wrote:
>> The pep has been updated with the excellent suggestions thus far.
>>
>> Are there any more?
>
> Thanks for writing the PEP.
>
> I tried a few of the common scenarios that I use at work. Disclaimer:
> my comments are based on my work environment.
>
> I was surprised that IP('172.16.1.1') returned
> IPv4Address('172.16.1.1/32') instead of IPv4Address('172.16.1.1'). I
> know I can change the behavior by using host=True, but then
> IP('172.16.1.1/24', host=True) will raise an error. It makes more
> sense, at least to me, that if I input just an IP address, I get an IP
> address back. I would prefer that IP('172.16.1.1/32') return an
> IPv4Network and IP('172.16.1.1') return an IPv4Address.
I think you mean that it returns an IPv4Network object (not
IPv4Address). My suggestion there is that if you know you're dealing
with an address, use one of the IPvXAddress classes (or pass host=True
to the IP function). IP is just a helper function and defaulting to a
network with a /32 prefix seems relatively common.
Knowing that my experience may not always be the most common, I can
change this behavior if it's indeed confusing, but in my conversations
with others and in checking out the current state of ip address
libraries, this seems to be a perfectly acceptable default.
> Would it be possible to provide an iterator that returns just the
> valid host IP addresses (minus the network and broadcast addresses)?
> "for i in IPv4Network('172.16.1.0/28')" and "for in in
> IPv4Network('172.16.1.0/28').iterhosts()" both return all 16 IP
> addresses. I normally describe 172.16.1.0/28 as consisting of one
> network address, 14 host addresses, and one broadcast address. I would
> prefer that "for i in IPv4Network('172.16.1.0/28')" return all IP
> addresses and that "for in in
> IPv4Network('172.16.1.0/28').iterhosts()" exclude the network and
> broadcast addresses. I think creating a list of IP addresses that can
> be assigned to devices on a network is a common task.
this is a good idea and I'll implement this. .iterhosts() for subnet
- (network|broadcast) and .iterallhosts() for the entire subnet (in my
testing, looping over an iterator was actually reasonably faster than
just for i in IP(network):, so I'll support iterators for both)
> Can .subnet() be enhanced to accept masks? For example,
> IPv4Network('172.16.0.0/16').subnet('/19') would return the eight /19
> subnets.
This seems like an easy win. I'll implement this too.
> What about supporting multiple parameters to subnet? I frequently need
> to create complex subnet layouts. The following subnet layout is NOT
> made up!
I believe it, we have equally odd subnet assignments at work.
[snip]
>
> A possible syntax would be:
> .subnet((1,'/23'),(1,'/25'),(2,'/26'),(2,'/28'),(8,'/30'),(16,'/32'),(3,'/28'),(2,'/27'),(1,'/26'))
>
> Note: I am willing to provide patches to implement my suggestions. I
> just won't have much time over the next couple weeks.
I'm happy reviewing/accepting patches to ipaddr. I'd worry a bit about
the complexity required for this, but I'm open-minded.
> casevh
>
>
>> Cheers,
>> /peter
>>
>> On Tue, Aug 18, 2009 at 1:00 PM, Peter Moody wrote:
>>> Howdy folks,
>>>
>>> I have a first draft of a PEP for including an IP address manipulation
>>> library in the python stdlib. It seems like there are a lot of really
>>> smart folks with some, ahem, strong ideas about what an IP address
>>> module should and shouldn't be so I wanted to solicit your input on
>>> this pep.
>>>
>>> the pep can be found here:
>>>
>>> http://www.python.org/dev/peps/pep-3144/
>>>
>>> the code can be found here:
>>>
>>> http://ipaddr-py.googlecode.com/svn/branches/2.0.x/
>>>
>>> Please let me know if you have any comments (some already coming :)
>>>
>>> Cheers,
>>> /peter
>>>
>> ___
>> 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/casevh%40gmail.com
>>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
Peter Moody wrote:
this is a good idea and I'll implement this. .iterhosts() for subnet
> - (network|broadcast) and .iterallhosts() for the entire subnet (in my
> testing, looping over an iterator was actually reasonably faster than
> just for i in IP(network):, so I'll support iterators for both)
I would suggest just changing __iter__ to be the equivalent of the
current iterhosts() and then changing iterhosts() as described.
Such a change would would also fix the thread safety and nested
iteration problems problems suffered by the current __iter__
implementation. I haven't executed the following, but from reading the
code I am confident they would behave as a I describe in the comments:
# With the current implementation, this is an infinite loop
net = IPv4Network("192.168.2.0")
for x in net:
iter(net)
# And this only runs the inner loop once
for x in net:
for y in net:
pass
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
Peter Moody wrote:
> On Thu, Aug 20, 2009 at 10:15 PM, Case Vanhorsen wrote:
>> I was surprised that IP('172.16.1.1') returned
>> IPv4Address('172.16.1.1/32') instead of IPv4Address('172.16.1.1'). I
>> know I can change the behavior by using host=True, but then
>> IP('172.16.1.1/24', host=True) will raise an error. It makes more
>> sense, at least to me, that if I input just an IP address, I get an IP
>> address back. I would prefer that IP('172.16.1.1/32') return an
>> IPv4Network and IP('172.16.1.1') return an IPv4Address.
>
> I think you mean that it returns an IPv4Network object (not
> IPv4Address). My suggestion there is that if you know you're dealing
> with an address, use one of the IPvXAddress classes (or pass host=True
> to the IP function). IP is just a helper function and defaulting to a
> network with a /32 prefix seems relatively common.
>
> Knowing that my experience may not always be the most common, I can
> change this behavior if it's indeed confusing, but in my conversations
> with others and in checking out the current state of ip address
> libraries, this seems to be a perfectly acceptable default.
The IP() helper function actually bothers me a bit - it's a function
where the return *type* depends on the parameter *value*. While
switching between IPv4 and IPv6 based on value is probably a necessary
behaviour, perhaps it would be possible to get rid of the "host=True"
ugliness and instead have two separate helper functions:
IP() - returns either IPv4Address or IPv6Address
IPNetwork() - returns either IPv4Network or IPv6Network
Both would still accept a version argument, allowing programmatic
control of which version to accept. If an unknown version is passed then
some kind of warning or error should be emitted rather than the current
silent fallback to attempting to guess the version based on the value.
I would suggest removing the corresponding IPv4 and IPv6 helper
functions altogether.
My rationale for the above is that hosts and networks are *not* the same
thing. For any given operation, the programmer should know whether they
want a host or a network and ask for whichever one they want. The
IPv4/IPv6 distinction, on the other hand, is something that a lot of
operations are going to be neutral about, so it makes sense to deal with
the difference implicitly.
Other general comments:
- the module appears to have quite a few isinstance() checks against
non-abstract base classes. Either these instance checks should all be
removed (relying on pure duck-typing instead) or else the relevant
classes should be turned into ABCs. (Note: this comment doesn't apply to
the type dispatch in the constructor methods)
- the reference implementation has aliased "CamelCase" names with the
heading "backwards compatibility". This is inappropriate for a standard
library submission (although I can see how it would be useful if you
were already using a different IP address library).
- isinstance() accepts a tuple of types, so isinstance(address, (int,
long)) is a shorter way of writing "isinstance(address, int) or
isinstance(address, long)". The former also has the virtue of executing
faster. However, an even better approach would be to use
operator.index() in order to accept all integral types rather than just
the builtin ones.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
Dj Gilcrease writes: > On Fri, Aug 21, 2009 at 8:19 AM, Dirkjan Ochtman wrote: >> Enabling extensions in a versioned file is not going to fly. > > any specific reason? In the general case, you can specify an extension to be enabled by filename: [extensions] foo = ~/src/foo So if I can enable an extension like that on your system, I might be evil and commit a bad extension *and* enable it at the same time. You might argue that one should then limit which extensions one can enable in a versioned file, but it seems hard to come up with a good mechanism for this. The current "mechanism" is the users own ~/.hgrc file which can be seen as a whitelist of extensions he trust. An alternative could be the new %include syntax for configuration files, which was introduced in Mercurial 1.3. If you add %include ../config to your .hg/hgrc file, the (versioned!) file named 'config' from the root of your repository will be included on the spot. The catch is that you have to add such a line to all your Python clones. -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgpFj5YhluRNP.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issue 1170: Unicode for ‘shlex ’
Howdy all, What is the procedure for finding out why an issue hasn't progressed? I don't want to fill the bug database with such noise. In the case of http://bugs.python.org/issue1170> (“shlex have problems with parsing unicode”), the problem is apparently addressed by a patch, assigned to that issue since 2007-12-22. There is no indication in the report why it's not yet applied. I'd really like this fixed in the 2.x series if possible. -- \ “… whoever claims any right that he is unwilling to accord to | `\ his fellow-men is dishonest and infamous.” —Robert G. | _o__) Ingersoll, _The Liberty of Man, Woman and Child_, 1877 | Ben Finney ___ 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] Mercurial migration: help needed
On 22/08/2009 12:19 AM, Dirkjan Ochtman wrote:
On Fri, Aug 21, 2009 at 16:10, Dj Gilcrease wrote:
I like this, though maybe .hgextensions since it would contain
versioned rules and the actual required extension. The extra sub
directories are not really required IMHO, you just have a hgrc file
that works the same as the local hgrc file except it only looks in the
.hgextensions directory for the correct extension so for python we
could have something like
[extensions]
format_enforcer =
Enabling extensions in a versioned file is not going to fly.
I like Stephen and Nick's discussion higher in this thread, but wonder
if some middle ground couldn't work.
Instead of [extensions], just have a place to list the required
extensions - eg;
Something like ~/.hgrules having:
[config] # or maybe [rules] ?
required_extensions = win32text, some_pydev_specific_extension
[encode]
{rules for encoding}
[pydev]
some_custom_property_for_our_custom_ext = 1
... etc ...
(Note I am not proposing we need out own pydev_specific_extension, I
just included it here to try and show the more general concept)
This way you aren't *enabling* extensions in this versioned file, just
listing rules about what extensions must be enabled. From core hg's
POV, it doesn't care if the required extensions relate to windows line
endings or re-encoding images - it just honours the wishes of the repo
owner.
From earlier in the thread, Dirkjan writes:
> The [concept of hg enforing required extensions] might indeed be
> hard to get into the core, but seems like a good idea to try.
From my POV, this would be required in some form or another before such
a scheme could actually work. Without it we end up with an improved
win32text (good!) but in practice still have the same problems we have
discussed in this thread which would make it unsuitable for us who
actually try and use it, particularly as a general solution for projects
with any kind of windows focus or community.
Given you are a core hg committer and well known in the community, would
you be willing to start a thread with the hg developers about this
issue? If something like this can't get into the core, I will drop any
expectations of it becoming a viable general solution for windows
focused projects, so would limit the work I am willing to invest to the
commitments I've made here.
Thanks!
Mark
___
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] Mercurial migration: help needed
On 22/08/2009 12:10 AM, Dj Gilcrease wrote: On Fri, Aug 21, 2009 at 1:16 AM, Mark Hammond wrote: Maybe you can enumerate what you think needs to change in mercurial, then once we have a plan in place it will be clearer who can do what. The encode/decode hooks need to be passed the filename they are working on so you can have an ignore list, this is why I consider my method a hack since I am using a precommit hook to do conversion since I am able to find out which file I am working on and make sure it is not in an ignore list. There also needs to be a way to have required and version controlled extensions. I think this is the exact issue my 'none' patch addresses. Your filters can say: [encode] *.dsp=none: **=cleverencode: The end result should be that anything with 'none:' forms what you call an ignore list. Would that not meet your requirements? Cheers, Mark ___ 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] Mercurial migration: help needed
Mark Hammond writes:
> Something like ~/.hgrules having:
Surely you mean $PROJECTROOT/.hgrules?
> [config] # or maybe [rules] ?
> required_extensions = win32text, some_pydev_specific_extension
[extensions]
required_for_commit = win32text,some_other_ext
That might require a change to hg's ini file semantics if currently it
refuses to parse [extension] sections in versioned hgrcs.
Note the change in name: I'm not sure exactly what the semantics
should be, but surely we want to allow browsing the repository,
branching, etc without enabling any extensions.
> [Encode]
> {rules for encoding}
No, there must be a way to indicate that "this is a section for a
specific extension". Bare [Encode] will be seen as polluting the
global namespace, and will get a lot of pushback, I think.
> This way you aren't *enabling* extensions in this versioned file,
True, but how many people will just download the extension and enable
it? This would open a door to "social engineering". (Personally, *I*
am not opposed to it on those grounds, but as devil's advocate I do
want to mention that as an argument you might run into.)
> just listing rules about what extensions must be enabled. From
> core hg's POV, it doesn't care if the required extensions relate to
> windows line endings or re-encoding images - it just honours the
> wishes of the repo owner.
If it refuses the user's request, it should issue a message to the
effect of "Please enable win32text, which is required in ."
___
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] Mercurial migration: help needed
On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
Mark Hammond writes:
> Something like ~/.hgrules having:
Surely you mean $PROJECTROOT/.hgrules?
Indeed.
> [config] # or maybe [rules] ?
> required_extensions = win32text, some_pydev_specific_extension
[extensions]
required_for_commit = win32text,some_other_ext
That might require a change to hg's ini file semantics if currently it
refuses to parse [extension] sections in versioned hgrcs.
Yes - I'm not proposing specific names for sections etc - I'm more
interested in getting the concepts across, and fully expect the hg guys
will have their own opinions and make final decisions on the exact spelling.
Note the change in name: I'm not sure exactly what the semantics
should be, but surely we want to allow browsing the repository,
branching, etc without enabling any extensions.
> [Encode]
> {rules for encoding}
No, there must be a way to indicate that "this is a section for a
specific extension". Bare [Encode] will be seen as polluting the
global namespace, and will get a lot of pushback, I think.
Possibly - although I would expect the existing section names be reused
when applied to a versioned file, I'd be more than happy for the hg guys
to declare new names are appropriate for this.
> This way you aren't *enabling* extensions in this versioned file,
True, but how many people will just download the extension and enable
it?
In the ideal world, exactly as many people who would read the Python
developer guide, then download and install the extension based purely on
that. IOW, it is Python itself setting the policy, so people need to
make their own decisions based on that, regardless of whether the tool
enforces it or not.
This would open a door to "social engineering". (Personally, *I*
am not opposed to it on those grounds, but as devil's advocate I do
want to mention that as an argument you might run into.)
> just listing rules about what extensions must be enabled. From
> core hg's POV, it doesn't care if the required extensions relate to
> windows line endings or re-encoding images - it just honours the
> wishes of the repo owner.
If it refuses the user's request, it should issue a message to the
effect of "Please enable win32text, which is required in."
Agreed.
Thanks,
Mark
___
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] Issue 1170: Unicode for ‘shlex ’
2009/8/21 Ben Finney : > Howdy all, > > What is the procedure for finding out why an issue hasn't progressed? I > don't want to fill the bug database with such noise. In this case, it's probably because no one officially maintains the shlex module at the moment. > > In the case of http://bugs.python.org/issue1170> (“shlex have > problems with parsing unicode”), the problem is apparently addressed by > a patch, assigned to that issue since 2007-12-22. There is no indication > in the report why it's not yet applied. I will leave a few initial comments. > > I'd really like this fixed in the 2.x series if possible. -- Regards, Benjamin ___ 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
