Re: [Python-Dev] Contributor Agreements for Patches - was [Jython-dev] Jython on Google AppEngine!
On Wed, Apr 8, 2009 at 8:37 PM, "Martin v. Löwis" wrote: --8<-- > > * Should we change the workflow for roundup to make this assignment > > of license clearer (see Tobias's idea in the thread about a > > click-though agreement). > > I think we do need something written; a lawyer may be able to tell > precisely. The company I work for does open source development. And our lawyers said that our model of having contributors send an e-mail with the text "I agree" and our CLA as an attachment was perfectly valid, no hand written signature needed. From there the step to a click through for something as simple as a patch isn't too far. But I would not claim that I know any of these things, I'm just hoping that we can have a simple process with no legal gray areas. > > > I still hope that we can record, in the tracker, which contributors have > signed an agreement. That would be good. Cheers, Tobias ___ 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] Contributor Agreements for Patches - was [Jython-dev] Jython on Google AppEngine!
On Mon, Apr 13, 2009 at 4:44 PM, "Martin v. Löwis" wrote: > > * What is the scope of a patch that requires a contributor > > agreement? > > Van's advise is as follows: > > There is no definite ruling on what constitutes "work" that is > copyright-protected; estimates vary between 10 and 50 lines. > Establishing a rule based on line limits is not supported by > law. Formally, to be on the safe side, paperwork would be needed > for any contribution (no matter how small); this is tedious and > probably unnecessary, as the risk of somebody suing is small. > Also, in that case, there would be a strong case for an implied > license. > > So his recommendation is to put the words > > "By submitting a patch or bug report, you agree to license it under the > Apache Software License, v. 2.0, and further agree that it may be > relicensed as necessary for inclusion in Python or other downstream > projects." > > into the tracker; this should be sufficient for most cases. For > committers, we should continue to require contributor forms. Sounds great to me. Cheers, Tobias ___ 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] Scope object (Re: nonlocals() function?)
On Tue, Apr 6, 2010 at 11:13 AM, Greg Ewing wrote:
> Reid Kleckner wrote:
>
> If I remember correctly, the exec statement is going away in py3k, and
>> calling exec() with one argument can modify the local scope.
>>
>
> I've been kind of wondering what the deal is with exec in py3.
> I always thought the reason for making exec a statement was so
> that locals optimisation could be turned off in its presence,
> so I'm not sure how py3 is getting away with making it a
> function.
>
It looks like py3 does not allow exec to modify the locals:
$ python3
Python 3.1.1 (r311:74543, Aug 24 2009, 18:44:04)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def x(a):
... exec(a)
... return a
...
>>> x("a = 5")
'a = 5'
>>> # the above statement would have returned 5 if the locals had been
modified
>
> Anyhow, it seems to me that as long as locals() or whatever
> might replace it is able to find the existing value of a local,
> it should also be able to change that value, wherever it
> happens to be stored.
>
> I suppose that might fail if an optimiser decides to keep
> multiple copies of a local for some reason, though.
>
> But even if it has to be read-only, I still think a view object
> would be a more py3ish way of handling locals() and the like.
> You might only want access to a few locals, in which case
> building a dict containing all of them would be wasteful.
>
> --
> Greg
>
>
> --
> Greg
>
> ___
> 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/thobes%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] Unipath package
Hi!
I am a MSc of Computer Engineering student from Sweden. A frequent reader of
python-3000, and an occasional reader of python-dev for about a year now. I
have wanted to get involved in the development of python for a while but
haven't found the time before. Now, when I'm in the process of trying to
figure out what project to do for my thesis, I have actually found myself
having more time than before. Therefore I thought that now is a better time
than never to get involved. After that compulsory first-post-introduction of
myself, lets get to the reason I choose to send the post at all.
I noticed that you wanted Mac OS tests, here are the test results from my
Mac OS X (10.4), running on an Intel Core Duo MacBook, using python 2.5:
FF...F
==
FAIL: test_absolute (__main__.TestCalculatingPaths)
--
Traceback (most recent call last):
File "./test.py", line 235, in test_absolute
eq(p1, p2)
AssertionError: FSPath('/private/tmp/tmpH9fppC/images') !=
FSPath('/tmp/tmpH9fppC/images')
==
FAIL: test_chdir_absolute_relative (__main__.TestCalculatingPaths)
--
Traceback (most recent call last):
File "./test.py", line 220, in test_chdir_absolute_relative
eq(FSPath.cwd(), self.d)
AssertionError: FSPath('/private/tmp/tmpRJzqbt') != FSPath('/tmp/tmpRJzqbt')
==
FAIL: test_relative (__main__.TestCalculatingPaths)
--
Traceback (most recent call last):
File "./test.py", line 240, in test_relative
eq(p, "images")
AssertionError: FSPath('../../../tmp/tmpdw9juF/images') != 'images'
--
Ran 58 tests in 1.587s
Please let me know if there are any further tests or improvements I could
help you with.
/Tobias
On 1/28/07, Mike Orr <[EMAIL PROTECTED]> wrote:
I finally finished my path package (Unipath) and put it in the Cheeseshop.
http://sluggo.scrapping.cc/python/unipath/
There's a Path class for pathname calculations, and a FSPath subclass
for filesystem calls. I'm hoping Path -- or something resembling it
-- will find its way into os.path in Python 2.6 or 3.0. FSPath is
full of convenience methods so it may not be everybody's cup of tea,
but perhaps something similar can go into Python in the farther future
Unipath is an early alpha release so the API may change as it gets
more real-world use. There's an extensive unittest suite, which
passes on Python 2.5 and 2.4.4 on Linux. Windows and Macintosh
testers are needed.
Following are highlights from the python-3000 discussion and deviations
from it:
- Path subclasses unicode, or str if the platform can't handle
Unicode pathnames.
- FSPath subclasses Path. This allows you to do "from unipath import
FSPath as Path" and pretend there's only one class. I find this much
more convenient in applications, so you don't have to cast objects
back and forth between the classes. Also, it just became infeasable
not to let them inherit, because so many methods call other methods.
- Nevertheless, you can use Path alone and rest assured it will never
touch the filesystem. You can even use Path objects with os.*
functions if you are so heretically inclined. If Path is accepted
into the stdlib, FSPath will inherit it from there.
- I tried splitting FSPath into several mixins according to type of
operation, but the need for methods to call other methods in a
different category sabotaged that too. So FSPath proudly has about
fifty methods. (Path has 10 public methods and 4 properties.)
- The dirname property is called .parent. The basename property is
.name. The extension property is .ext. The name without extension is
.stem.
- .components() returns a list of directory components. The first
component is "/", a Windows drive root, a UNC share, or "" for a
relative path. .split_root() returns the root and the rest.
- PosixPath, NTPath, and MacPath are Path subclasses using a specific
path library. This allows you to express non-native paths and convert
paths. Passing a relative foreign path to a *Path constructor
converts it to the destination type. Passing an absolute foreign path
is an error, because there's no sane way to interpret "C:\\" on Posix
or "/" on Windows. I'm skeptical whether this non-native support is
really worth it, because .norm() and .norm_case() already convert
slashes to backslashes (which is what Talin really wanted to do --
have Posix paths in a config file and automatically convert them to
the native format). And if Python is going to drop Mac OS 9 soon then
MacPath is obsolete. So maybe this non-native path code
