[Python-Dev] trunk doctests fail to execute with 2.7 alpha
I can not compile Python itself, so I use Alpha version to run tests in trunk. Recent update broke successfully running tests. Any hints why this happened and how to fix them back? > C:\~env\Python27\python.exe test\test_doctest.py doctest (doctest) ... 66 tests with zero failures Traceback (most recent call last): File "test\test_doctest.py", line 2492, in test_main() File "test\test_doctest.py", line 2474, in test_main with test_support.check_warnings(*deprecations): File "C:\~env\Python27\lib\contextlib.py", line 84, in helper return GeneratorContextManager(func(*args, **kwds)) TypeError: check_warnings() takes no arguments (1 given) -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacing threads with swapcontext()
Nick Coghlan wrote: Off the top of my head, recursion limit checks will definitely go haywire, and I would expect threading.local() and exception handling to explode at some point (although the latter depends on what you mean by "switching C stacks" - if you really are just fiddling the stack pointer without affecting the thread local heap storage mechanisms, the latter two should be fine. Still doesn't sound like a good idea though). In my implementation, each context looks like a thread to Python, with its own PyThreadState, thread-local storage and locks are taken care of, so I'm reasonably sure there's nothing scary lurking unseen. I'm trying to confirm my understanding as to how unreliable the greenlet is. The greenlet module basically just switches C stacks and does not touch anything else. There evidently are problems with this when there's an exception raised, as it's stored in PyThreadState::curexc_*/exc_*. PyThreadState's profiling/tracing -related members, the tick_counter, and per-thread state dict don't appear as a problem at the first glance. recursion_depth will be messed up unpredictably, as you kindly pointed out. This leaves PyThreadState::frame a PyFrameObject to be examined. Do they form a python-side stack of a thread in question? -- ./lxnt ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Modifying Grammar/grammar and other foul acts
Thank you for the advice everyone. This seed has finally born (rotten)
fruit at:
http://writeonly.wordpress.com/2010/04/01/whython-python-for-people-who-hate-whitespace/
http://bitbucket.org/gregglind/python-whython3k/
On Fri, Mar 12, 2010 at 4:13 AM, Georg Brandl wrote:
> Am 09.03.2010 14:42, schrieb Jeremy Hylton:
> > On Sat, Mar 6, 2010 at 11:27 AM, Gregg Lind
> wrote:
> >> Python-devs,
> >>
> >> I'm writing to you for some help in understanding the Python grammar.
> As an
> >> excuse to deep dive into Python's tokenizer / grammar, I decided (as a
> >> hideous, hideous joke) to want to allow braces where colons are allowed
> (as
> >> flow control).
> >>
> >> Starting from PEP 306 (and branch r311), I hacked on Grammar/Grammer
> >>
> >> As a first example:
> >>
> >> funcdef: ('def' NAME parameters ['->' test] ':' suite |
> >> 'def' NAME parameters ['->' test] '{' suite '}' )
> >>
> >> I reran Parser/pgen and the dfa changes, but python (3.1) when
> recompiled,
> >> throws errors on things like:
> >>
> >> def a() { None }
> >>
> >> Strangely enough:
> >>
> >> lambdef: ( 'lambda' [varargslist] ':' test |
> >>'lambda' [varargslist] '{' test '}' )
> >>
> >> works fine! I this simplely some difference between "test" and "suite".
> >>
> >> I have tried tackling this with gdb, looking at err_input clearly isn't
> >> enough.
> >>
> >> (gdb) break err_input
> >> (gdb) break PyParser_ASTFromString
> >> import sys
> >> b = compile("def a() {pass}","sys.stdout","single")
> >> # yet a simple grammar fix is enough for this!
> >> c = compile("lambda x {None}","sys.stdout","single")
> >>
> >> I'm in over my head!
> >
> > You don't say what errors occur when you try to compile strings in
> > your new language. You may have changed the Grammar, which allows you
> > to tokenize the input. That isn't enough to get the input to compile.
> > You also need to change the compiler to understand the new tokens.
>
> In particular, many AST creation functions check for specific counts of
> children on many nodes. I haven't checked, but in the case of the
> "funcdef" rule, it may check for either 7 or 5 children to determine
> whether the optional return annotation ['->' test] is present.
>
> Georg
>
>
> --
> Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
> Four shall be the number of spaces thou shalt indent, and the number of thy
> indenting shall be four. Eight shalt thou not indent, nor either indent
> thou
> two, excepting that thou then proceed to four. Tabs are right out.
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/gregg.lind%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk doctests fail to execute with 2.7 alpha
On 01/04/2010 10:05, anatoly techtonik wrote: I can not compile Python itself, Building Python on Windows can be done with free tools, so it should be possible for you to build Python. See the instructions here: http://python.org/dev/faq/#id8 so I use Alpha version to run tests in trunk. Recent update broke successfully running tests. Any hints why this happened and how to fix them back? C:\~env\Python27\python.exe test\test_doctest.py doctest (doctest) ... 66 tests with zero failures Traceback (most recent call last): File "test\test_doctest.py", line 2492, in test_main() File "test\test_doctest.py", line 2474, in test_main with test_support.check_warnings(*deprecations): File "C:\~env\Python27\lib\contextlib.py", line 84, in helper return GeneratorContextManager(func(*args, **kwds)) TypeError: check_warnings() takes no arguments (1 given) When I run this test with a freshly built Python I get the following: :\compile\python-trunk\PCbuild > python_d.exe ..\Lib\test\test_doctest.py doctest (doctest) ... 66 tests with zero failures doctest (test.test_doctest) ... 428 tests with zero failures [42795 refs] All the best, Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk doctests fail to execute with 2.7 alpha
Thanks. I've copied test/test_support.py form Lib into 2.7 alpha directory and it seems to work. Although it doesn't seem good to me to mix test support library with tests themselves. -- anatoly t. On Thu, Apr 1, 2010 at 2:18 PM, Michael Foord wrote: > On 01/04/2010 10:05, anatoly techtonik wrote: >> >> I can not compile Python itself, > > Building Python on Windows can be done with free tools, so it should be > possible for you to build Python. > > See the instructions here: > > http://python.org/dev/faq/#id8 > >> so I use Alpha version to run tests >> in trunk. Recent update broke successfully running tests. Any hints >> why this happened and how to fix them back? >> >> >>> >>> C:\~env\Python27\python.exe test\test_doctest.py >>> >> >> doctest (doctest) ... 66 tests with zero failures >> Traceback (most recent call last): >> File "test\test_doctest.py", line 2492, in >> test_main() >> File "test\test_doctest.py", line 2474, in test_main >> with test_support.check_warnings(*deprecations): >> File "C:\~env\Python27\lib\contextlib.py", line 84, in helper >> return GeneratorContextManager(func(*args, **kwds)) >> TypeError: check_warnings() takes no arguments (1 given) >> >> > > When I run this test with a freshly built Python I get the following: > > :\compile\python-trunk\PCbuild >> python_d.exe ..\Lib\test\test_doctest.py > doctest (doctest) ... 66 tests with zero failures > doctest (test.test_doctest) ... 428 tests with zero failures > [42795 refs] > > All the best, > > > Michael Foord > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > READ CAREFULLY. By accepting and reading this email you agree, on behalf of > your employer, to release me from all obligations and waivers arising from > any and all NON-NEGOTIATED agreements, licenses, terms-of-service, > shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, > non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have > entered into with your employer, its partners, licensors, agents and > assigns, in perpetuity, without prejudice to my ongoing rights and > privileges. You further represent that you have the authority to release me > from any BOGUS AGREEMENTS on behalf of your employer. > > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk doctests fail to execute with 2.7 alpha
On 01/04/2010 13:15, anatoly techtonik wrote: Thanks. I've copied test/test_support.py form Lib into 2.7 alpha directory and it seems to work. Although it doesn't seem good to me to mix test support library with tests themselves. What do you mean by "it doesn't seem good to me to mix test support library with tests themselves"? Do you mean to have it in the same directory - where would you put it? It isn't *meant* to be a public library, it exists only to support the test framework. In Python 3 it has been renamed support.py, but lives in the same location. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk doctests fail to execute with 2.7 alpha
On Thu, Apr 1, 2010 at 3:59 PM, Michael Foord wrote: >> >> Thanks. I've copied test/test_support.py form Lib into 2.7 alpha >> directory and it seems to work. >> Although it doesn't seem good to me to mix test support library with >> tests themselves. >> > > What do you mean by "it doesn't seem good to me to mix test support library > with tests themselves"? Do you mean to have it in the same directory - where > would you put it? It isn't *meant* to be a public library, it exists only to > support the test framework. In Python 3 it has been renamed support.py, but > lives in the same location. I mean that usually testing tools/libraries are separated from tests itself, as well as data. test_support.py is not only located in the same directory - it is even named in the same way. The test directory looks like a mess with all these aux data files. But it is hard to estimate if it would be worthy to separate testing framework from tests and test data. It may happen that writing and debugging tests become harder, because Python is not locked into some specific usage domain. -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk doctests fail to execute with 2.7 alpha
anatoly techtonik wrote: > I mean that usually testing tools/libraries are separated from tests > itself, as well as data. test_support.py is not only located in the > same directory - it is even named in the same way. The test directory > looks like a mess with all these aux data files. But it is hard to > estimate if it would be worthy to separate testing framework from > tests and test data. It may happen that writing and debugging tests > become harder, because Python is not locked into some specific usage > domain. Tests start with test_*, the support files don't. The only odd one out was test_support, and that has been fixed for 3.x. The generalised test frameworks (unittest, doctest) do live in the standard library. It's only the stuff specific to *our* unit tests that lives in the test directory (and certainly, things from that directory will sometimes get generalised and moved to the standard library - that's how warning.catch_warnings was created). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Modifying Grammar/grammar and other foul acts
Gregg Lind wrote: > Thank you for the advice everyone. This seed has finally born (rotten) > fruit at: > > http://writeonly.wordpress.com/2010/04/01/whython-python-for-people-who-hate-whitespace/ > http://bitbucket.org/gregglind/python-whython3k/ Nicely done :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] skip all TestCase methods if resource is not available
Currently it is possible to mark individual test methods with:
test_support.requires('network')
However, sometimes it is necessary to skip the whole TestCase if
'network' resource is not available counting the number of skipped
tests at the same time. Are there any standard means to do this?
--
anatoly t.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] skip all TestCase methods if resource is not available
2010/4/1 anatoly techtonik:
> Currently it is possible to mark individual test methods with:
>test_support.requires('network')
>
> However, sometimes it is necessary to skip the whole TestCase if
> 'network' resource is not available counting the number of skipped
> tests at the same time. Are there any standard means to do this?
Put it in unittest.TestCase.setUp() method. It should be enough.
--
Florent
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] skip all TestCase methods if resource is not available
On Thu, Apr 1, 2010 at 8:02 PM, Florent Xicluna
wrote:
> 2010/4/1 anatoly techtonik:
>> Currently it is possible to mark individual test methods with:
>> test_support.requires('network')
>>
>> However, sometimes it is necessary to skip the whole TestCase if
>> 'network' resource is not available counting the number of skipped
>> tests at the same time. Are there any standard means to do this?
>
> Put it in unittest.TestCase.setUp() method. It should be enough.
It fails with error instead if skip, as it should according to
http://docs.python.org/library/unittest.html#unittest.TestCase.setUp
"...any exception raised by this method will be considered an error
rather than a test failure..."
--
anatoly t.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] skip all TestCase methods if resource is not available
2010/4/1 anatoly techtonik: > On Thu, Apr 1, 2010 at 8:02 PM, Florent Xicluna wrote: (...) >> >> Put it in unittest.TestCase.setUp() method. It should be enough. > > It fails with error instead if skip, as it should according to > http://docs.python.org/library/unittest.html#unittest.TestCase.setUp > > "...any exception raised by this method will be considered an error > rather than a test failure..." > -- > anatoly t. > There's a special case for the "SkipTest" exception in 2.7 (even if it is not documented). try: self.setUp() except SkipTest as e: self._addSkip(result, str(e)) except Exception: result.addError(self, sys.exc_info()) But for 2.6, you're right: try: self.setUp() except: result.addError(self, self._exc_info()) -- Florent ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3147 working implementation
I now have a working implementation of PEP 3147 which passes all the existing, and new, tests. I'm sure there's still work to do, but I think the branch is in good enough shape to start getting some feedback from python-dev. You can grab the changes in several ways. If you have Bazaar, you can check out the branch by doing: % bzr branch lp:~barry/python/pep3147 You can also view a live diff online: https://code.launchpad.net/~barry/python/pep3147/+merge/22648 or just download the diff, which should apply cleanly against the py3k Subversion branch (or pretty close): https://code.launchpad.net/~barry/python/pep3147/+merge/22648/+preview-diff/+files/preview.diff Modulo some lag time, the diffs should track changes I make to the branch. You can provide feedback to me directly, as a follow up to this message, or in Launchpad. I've also updated the PEP to point to these locations for the reference implementation. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147 working implementation
Barry Warsaw python.org> writes: > > You can also view a live diff online: > > https://code.launchpad.net/~barry/python/pep3147/+merge/22648 If you want a review, perhaps you should post it to Rietveld. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proposing PEP 376
Hello, On behalf of the distutils-SIG, I'd like to propose PEP 376 for inclusion. This PEP is about defining a standard for installed Python projects. http://www.python.org/dev/peps/pep-0376/ It was created : - to allow interoperability among all package managers. - to provide a set of APIs in the stdlib to know what's installed (in pkgutil) - to provide a basic *uninstaller* feature in the distutils2 project. It is very similar to the retired PEP 262, but closer to the standard the Setuptools project have created, which is quite used in the community. Calendar-wise, I'd love to see it accepted for 2.7 but it might be too late to finish discussing it (2.7b1 is due in a few days). So I guess the next target will be Python 3.2. One topic has been ignored on purpose in this PEP : how to describe in a detailed way the resources file a project contains, and how they should be installed on a FHS-compliant system (like, a configuration file should go in /etc and such things) We are currently focusing our discussion efforts on the resource files (see the summary work so far here : http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst) and we will produce another PEP for that, that will not interfer with PEP 376. Regards Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147 working implementation
On Apr 01, 2010, at 09:27 PM, Antoine Pitrou wrote: >If you want a review, perhaps you should post it to Rietveld. Good idea. http://codereview.appspot.com/842043/show I've never used Rietveld before so let me know if I need to do anything to invite you or otherwise make the review possible. I will update the PEP. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] copying of itertools iterators
using of copy.copy for simple iterators is forbidden >>> import copy >>> copy.copy(iter([1, 2, 3])) Traceback (most recent call last): File "", line 1, in File "/home/andrew/projects/py3k/Lib/copy.py", line 96, in copy return _reconstruct(x, rv, 0) File "/home/andrew/projects/py3k/Lib/copy.py", line 284, in _reconstruct y = callable(*args) File "/home/andrew/projects/py3k/Lib/copyreg.py", line 88, in __newobj__ return cls.__new__(cls, *args) TypeError: object.__new__(list_iterator) is not safe, use list_iterator.__new__() That behavior is safe and clean. But it's possible to copy iterator objects returned by itertools functions: >>> i = itertools.chain([1, 2], [3, 4, 5]) >>> i.__next__() 1 >>> j = copy.copy(i) >>> j.__next__() Traceback (most recent call last): File "", line 1, in StopIteration >>> i.__next__() 2 Looks like itertools object should be protected from usage like that. Folks, what are you think about? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 376
At 11:51 PM 4/1/2010 +0200, Tarek Ziadé wrote: Hello, On behalf of the distutils-SIG, I'd like to propose PEP 376 for inclusion. This PEP is about defining a standard for installed Python projects. http://www.python.org/dev/peps/pep-0376/ Very nice; I have only a few questions/suggestions, and some minor corrections. First, I notice the RECORD paths are listed as being relative to sys.prefix; I was under the impression that these paths were supposed to be relative to the base installation location of the library (i.e. site-packages in the default case). That is, that while paths not under sys.prefix were to be absolute, the paths under sys.prefix were relative to the install location. (Since one of the original motivating use cases for relative paths in RECORD was to support relocatable installations, and sharing installations across platforms, when the code is platform independent code.) Also, the spec doesn't address installation to paths that aren't under sys.prefix, or what happens if you use "setup.py install --prefix". I'm wondering if perhaps this should be restated as something like: * Paths under the base installation location are relative to the base * Paths not under the base installation location, but under the installation prefix, are also stored relative to the base, IF the base location is a subpath of the installation prefix * All other paths are absolute. Where "base location" is the effective --install-lib directory, and prefix is the effective --prefix. (Which default of course to site-package and sys.prefix respectively, but the spec shouldn't be in terms of those defaults.) Second, the RECORD spec is not clear on what happens to the hash field on .pyc/.pyo files. Is it supposed to be an empty string, a hash of an empty file, a hash value that's ignored, or...? Third, what is a "local absolute path"? This term appears several places but is not defined. It sounds like maybe you mean a path using the local platform separator, as opposed to a '/'-separated relative path. If that's the case, this should probably be spelled out somewhere early on and then referenced in context. Fourth, the PEP says the implementation will support zipfiles, but the draft implementation doesn't appear to support zipimport subdirectories. (Zipimport paths can be /path/to/some.zip/subdir, and this base is then used for importing, just as if the zipfile were a normal parent directory.) If this is an intentional omission, it should probably be mentioned in the PEP. Okay, on to the minor corrections. The following uses of "package" should be replaced by "project" or "distribution": "If a package that was already installed on the system as a dependency" "in other words, whether the package was installed by user request" "$ python -m distutils.uninstall packagename" Anyway, that's my first pass through; I think the RECORD section may need further fleshing out (e.g., specifying a particular csv-module dialect) in order to ensure that the spec is sufficiently rigorous for multiple tools to consume/produce compatible files. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] copying of itertools iterators
On Apr 1, 2010, at 4:20 PM, Andrew Svetlov wrote: > using of copy.copy for simple iterators is forbidden > import copy copy.copy(iter([1, 2, 3])) > Traceback (most recent call last): > File "", line 1, in > File "/home/andrew/projects/py3k/Lib/copy.py", line 96, in copy >return _reconstruct(x, rv, 0) > File "/home/andrew/projects/py3k/Lib/copy.py", line 284, in _reconstruct >y = callable(*args) > File "/home/andrew/projects/py3k/Lib/copyreg.py", line 88, in __newobj__ >return cls.__new__(cls, *args) > TypeError: object.__new__(list_iterator) is not safe, use > list_iterator.__new__() > > That behavior is safe and clean. > But it's possible to copy iterator objects returned by itertools functions: > i = itertools.chain([1, 2], [3, 4, 5]) i.__next__() > 1 j = copy.copy(i) j.__next__() > Traceback (most recent call last): > File "", line 1, in > StopIteration i.__next__() > 2 > > Looks like itertools object should be protected from usage like that. > Folks, what are you think about? > I find it hard to get excited about this. It doesn't seem to have been a problem in the real world (no complaints, bug reports, or feature requests). The tee() itertool is the official way to split-out an iterator stream -- it is also copyable with copy.copy(). The itertools.count() function is also copyable. Running copy.copy() on other itertools is currently undefined (though I may add copy support to itertools.repeat() and the combinatoric functions). Also, I seems to me the copy.copy() is itself not very bright about what it tries to copy and in giving clear messages about whether or not it successfully made a copy. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] copying of itertools iterators
On 4/1/2010 7:20 PM, Andrew Svetlov wrote: using of copy.copy for simple iterators is forbidden import copy copy.copy(iter([1, 2, 3])) Traceback (most recent call last): File "", line 1, in File "/home/andrew/projects/py3k/Lib/copy.py", line 96, in copy return _reconstruct(x, rv, 0) File "/home/andrew/projects/py3k/Lib/copy.py", line 284, in _reconstruct y = callable(*args) File "/home/andrew/projects/py3k/Lib/copyreg.py", line 88, in __newobj__ return cls.__new__(cls, *args) TypeError: object.__new__(list_iterator) is not safe, use list_iterator.__new__() The same happens for the iterators of other builtin classes: tuples, sets, and dicts (that I tried). In the other hand, >>> copy.copy(iter(range(1,3,1))) # 3.1 Traceback (most recent call last): ... TypeError: rangeiter() requires 3 int arguments and similar for filter and map. I do not know whether the former group is detected by rule or explicit hard-coded list, but I suspect the latter. That behavior is safe and clean. But it's possible to copy iterator objects returned by itertools functions: i = itertools.chain([1, 2], [3, 4, 5]) i.__next__() 1 j = copy.copy(i) This works because itertools.chain() is legal j.__next__() Traceback (most recent call last): File "", line 1, in StopIteration Because itertools.chain() is empty. i.__next__() 2 Looks like itertools object should be protected from usage like that. I suspect only those for which itertools.xxx() works rather than raising an exception. Folks, what are you think about? Why privilige the itertools module? A possible rule would be to not copy anything with both .__iter__ and .__next__. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 376
First: thank you distutils-sig, and especially Tarek, for spearheading this effort! I'm particularly excited about the "Distribution" object that this PEP specifies. I've been waiting for a long time to be able to load an object describing a distribution, rather than running setup.py and hoping that it mutated the right state! On Apr 1, 2010, at 5:51 PM, Tarek Ziadé wrote: > - to provide a basic *uninstaller* feature in the distutils2 project. Second: It seems to me that a major missing feature in the PEP is the ability to run some code during installation and uninstallation, especially since it is so easy to run ad-hoc code in setup.py with no way of un-doing what it did. Twisted's plugin system needs this in order to update a plugin index so that plugins can be quickly scanned without being loaded. However, since this is arguably a design flaw in Twisted that should be fixed, I should point out there are other systems that have similar requirements, which are considerably less mutable: COM registration, other registry keys, adding / removing crontab entries, windows services, start menu items, XDG desktop / menu entries, login items, edits to the user's shell configuration, etc. The list goes on and on. I appreciate the "installer marker" feature, since that will at least allow easy_install or pip or something like them to implement this feature with minimal risk of being broken by built-in package management tools, but it seems like such a simple addition that it would be a shame to leave it out. If we could get rid of setup.py entirely so that it wasn't so easy to run ad-hoc stuff during install, I would be happy to leave it to them :). I realize that there are a lot of potential complexities that might creep into the process of determining the execution environment for the code in question, but I personally think it would be good enough to say "You'd better be darn sure to encode all of the run-time state that you need into your own script, or it might break." Third: The PEP is silent on what happens to files whose hash _has_ changed from its install-time value. I guess the implied plan would be to leave them in place. However, this may have nasty side-effects; for example, if the files are test files, then they might be loaded during test discovery, and report exceptions since the code that they're testing has been removed. My suggestion would be to have a specific "quarantine" area where the distutils uninstaller can put modified files that would have been removed as part of a specific distribution, so they aren't still present on PYTHONPATH. I can also think of reasons why you might not want to do this, but either way, the consequence of changing an installed file should be made explicitly clear in the PEP: if they are to be left in place, it should emphasize that point. Finally, one minor bit of bikeshedding, of which I promise to say nothing more if there is not unanimous agreement: I dislike the use of "get_" in function names, since it adds more characters without really adding more information. get_file_users is particularly bad, since it makes me think that it's going to return a list of processes with a file open, or a list of UIDs or something like that. I suggest these names instead: get_distributions() -> active_distributions() get_distribution(name) -> active_distribution_named(name) get_file_users(path) -> distributions_using_path(path) where "active" means "on the current sys.path and thereby accessible by 'import'". This naming would also make the behavior of get_file_users a bit clearer; if the intention is to return only active, loadable distributions (you don't want to be able to use get_file_users to inspect other Python installations or virtualenvs) it could be called active_distributions_using_path. Thanks again to the PEP's author and many contributors, -glyph ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
