Re: [Python-Dev] [Python-checkins] cpython: Closes #21256: Printout of keyword args in deterministic order in mock calls.
On Mon, Jun 9, 2014 at 11:16 AM, kushal.das wrote: > http://hg.python.org/cpython/rev/8e05e15901a8 > changeset: 91102:8e05e15901a8 > user:Kushal Das > date:Mon Jun 09 13:45:56 2014 +0530 > summary: > Closes #21256: Printout of keyword args in deterministic order in mock > calls. > > Printout of keyword args should be in deterministic order in > a mock function call. This will help to write better doctests. > > files: > Lib/unittest/mock.py | 2 +- > Lib/unittest/test/testmock/testmock.py | 6 ++ > Misc/NEWS | 3 +++ > 3 files changed, 10 insertions(+), 1 deletions(-) > > > diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py > --- a/Lib/unittest/mock.py > +++ b/Lib/unittest/mock.py > @@ -1894,7 +1894,7 @@ > formatted_args = '' > args_string = ', '.join([repr(arg) for arg in args]) > kwargs_string = ', '.join([ > -'%s=%r' % (key, value) for key, value in kwargs.items() > +'%s=%r' % (key, value) for key, value in sorted(kwargs.items()) > ]) > if args_string: > formatted_args = args_string > diff --git a/Lib/unittest/test/testmock/testmock.py > b/Lib/unittest/test/testmock/testmock.py > --- a/Lib/unittest/test/testmock/testmock.py > +++ b/Lib/unittest/test/testmock/testmock.py > @@ -1206,6 +1206,12 @@ > with self.assertRaises(AssertionError): > m.hello.assert_not_called() > > +#Issue21256 printout of keyword args should be in deterministic order > +def test_sorted_call_signature(self): > +m = Mock() > +m.hello(name='hello', daddy='hero') > +text = "call(daddy='hero', name='hello')" > +self.assertEquals(repr(m.hello.call_args), text) Should this be assertEqual instead? --Berker > > def test_mock_add_spec(self): > class _One(object): > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -92,6 +92,9 @@ > Library > --- > > +- Issue #21256: Printout of keyword args should be in deterministic order in > + a mock function call. This will help to write better doctests. > + > - Issue #21677: Fixed chaining nonnormalized exceptions in io close() > methods. > > - Issue #11709: Fix the pydoc.help function to not fail when sys.stdin is > not a > > -- > Repository URL: http://hg.python.org/cpython > > ___ > Python-checkins mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-checkins > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] namedtuple implementation grumble
Le 09/06/2014 00:05, Raymond Hettinger a écrit : Another issue is that a straight abc wouldn't be sufficient. What we would really want is to check for is: 1) the presence of a _fields tuple (an abc can do this) 2) to check that all of the attribute names specified in _fields are defined (ABCMeta doesn't do this) 3) and that the type is a Sequence (ABCMeta can do this). An tricked-out ABC extension might be worth it if it provided some non-trivial mixin capabilities for implementing homegrown named tuples (not created by the factory function), but I don't think we want to go there. Instead of an ABC, why not a simple is_namedtuple() function? Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] cpython and python debugger documentation
On Sat Jun 07 2014 at 5:55:29 PM, Le Pa wrote: > Hi, > > I am interested in learning how the cpython interpreter is designed and > implemented, > and also how the python debugger works internally. My ultimate purpose is > to > modify > them for my distributed computing needs. Are there any documentations > on these please? I have done some goggling but failed to find anything > useful. > > Thanks you very much for your help! > The only documentation we have is (roughly) how the parser and compiler work, not the interpreter. As for pdb, it's written in Python so you can look at the source to see how that works without much issue. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Help with the build system and my first patch
On Mon Jun 09 2014 at 2:07:22 AM, Steven Stewart-Gallus < [email protected]> wrote: > Hello, > > I would like some help understanding the build system. I am currently > working on an issue (http://bugs.python.org/issue21627) and plan to > create some common functionality in Python/setcloexec.c and > Include/setcloexec.h that is conditionally compiled in on POSIX > systems and not on Windows systems. I need to extract this > functionality out from _Py_set_inheritable because it needs to run in > the dangerous context of right after a fork and I don't believe it can > throw exceptions. How can I conditionally compile some library code > for certain platforms only? > Do you mean other than potentially detecting something in the configure script and using an #ifdef guard? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython and python debugger documentation
Hello, On Mon, 09 Jun 2014 14:01:18 + Brett Cannon wrote: > On Sat Jun 07 2014 at 5:55:29 PM, Le Pa wrote: > > > Hi, > > > > I am interested in learning how the cpython interpreter is designed > > and implemented, > > and also how the python debugger works internally. My ultimate > > purpose is to > > modify > > them for my distributed computing needs. Are there any > > documentations on these please? I have done some goggling but > > failed to find anything useful. > > > > Thanks you very much for your help! > > > > The only documentation we have is (roughly) how the parser and > compiler work, not the interpreter. As for pdb, it's written in > Python so you can look at the source to see how that works without > much issue. But doing attentive googling will turn out a lot of 3rd-party blog posts which discuss various implementation aspects of CPython (and even alternative implementations). Some random links: http://tech.blog.aknin.name/category/my-projects/pythons-innards/ http://eli.thegreenplace.net/2010/09/18/python-internals-symbol-tables-part-1/ http://nedbatchelder.com/blog/200804/the_structure_of_pyc_files.html One should keep in mind that implementation evolves all the time, and any info in older docs may be obsolete. So, the ultimate reference is the source itself, but posts like above can be a good help to understand it more easily and effectively. -- Best regards, Paul mailto:[email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython and python debugger documentation
On Mon, Jun 9, 2014 at 7:50 AM, Paul Sokolovsky wrote: > Hello, > > On Mon, 09 Jun 2014 14:01:18 + > Brett Cannon wrote: > > > On Sat Jun 07 2014 at 5:55:29 PM, Le Pa wrote: > > > > > Hi, > > > > > > I am interested in learning how the cpython interpreter is designed > > > and implemented, > > > and also how the python debugger works internally. My ultimate > > > purpose is to > > > modify > > > them for my distributed computing needs. Are there any > > > documentations on these please? I have done some goggling but > > > failed to find anything useful. > > > > > > Thanks you very much for your help! > > > > > > > The only documentation we have is (roughly) how the parser and > > compiler work, not the interpreter. As for pdb, it's written in > > Python so you can look at the source to see how that works without > > much issue. > > But doing attentive googling will turn out a lot of 3rd-party blog > posts which discuss various implementation aspects of CPython (and even > alternative implementations). Some random links: > > http://tech.blog.aknin.name/category/my-projects/pythons-innards/ > > http://eli.thegreenplace.net/2010/09/18/python-internals-symbol-tables-part-1/ > FWIW I have a bunch of those, and the symbol table one is probably not the best for beginners. The whole category is here: http://eli.thegreenplace.net/category/programming/python/python-internals/ Eli ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] namedtuple implementation grumble
On Jun 9, 2014, at 4:40 AM, Antoine Pitrou wrote: > Instead of an ABC, why not a simple is_namedtuple() function? That would work. Raymond ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help with the build system and my first patch
> Do you mean other than potentially detecting something in the > configurescript and using an #ifdef guard? Yes, that works on a static function inside a file level but I need to conditionally include a whole file into the build. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython and python debugger documentation
On 6/9/2014 12:26 PM, Eli Bendersky wrote: On Mon, Jun 9, 2014 at 7:50 AM, Paul Sokolovsky mailto:[email protected]>> wrote: Hello, On Mon, 09 Jun 2014 14:01:18 + Brett Cannon mailto:[email protected]>> wrote: > On Sat Jun 07 2014 at 5:55:29 PM, Le Pa mailto:[email protected]>> wrote: > > > Hi, > > > > I am interested in learning how the cpython interpreter is designed > > and implemented, > > and also how the python debugger works internally. My ultimate > > purpose is to > > modify > > them for my distributed computing needs. Are there any > > documentations on these please? I have done some goggling but > > failed to find anything useful. > > > > Thanks you very much for your help! > > > > The only documentation we have is (roughly) how the parser and > compiler work, not the interpreter. As for pdb, it's written in > Python so you can look at the source to see how that works without > much issue. But doing attentive googling will turn out a lot of 3rd-party blog posts which discuss various implementation aspects of CPython (and even alternative implementations). Some random links: http://tech.blog.aknin.name/category/my-projects/pythons-innards/ http://eli.thegreenplace.net/2010/09/18/python-internals-symbol-tables-part-1/ FWIW I have a bunch of those, and the symbol table one is probably not the best for beginners. The whole category is here: http://eli.thegreenplace.net/category/programming/python/python-internals/ Perhaps someone could make a wiki entry such as PythonInternals with links such as these. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help with the build system and my first patch
On Mon Jun 09 2014 at 1:48:27 PM, Steven Stewart-Gallus < [email protected]> wrote: > > Do you mean other than potentially detecting something in the > > configurescript and using an #ifdef guard? > > Yes, that works on a static function inside a file level but I need to > conditionally include a whole file into the build. > Why specifically does the file itself be conditional? Typically you unconditionally include the whole file and then put the entire contents of it in a #ifdef guard. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Criticism of execfile() removal in Python3
Hello,
I was pleasantly surprised with the response to recent post about
MicroPython implementation details
(https://mail.python.org/pipermail/python-dev/2014-June/134718.html). I
hope that discussion means that posts about alternative implementations
are not unwelcome here, so I would like to bring up another (of many)
issues we faced while implementing MicroPython.
execfile() builtin function was removed in 3.0. This brings few
problems:
1. It hampers interactive mode - instead of short and easy to type
execfile("file.py") one needs to use exec(open("file.py").read()). I'm
sure that's not going to bother a lot of people - after all, the
easiest way to execute a Python file is to drop back to shell and
restart python with file name, using all wonders of tab completion. But
now imagine that Python interpreter runs on bare hardware, and its REPL
is the only shell. That's exactly what we have with MicroPython's
Cortex-M port. But it's not really MicroPython-specific, there's
CPython port to baremetal either - http://www.pycorn.org/ .
2. Ok, assuming that exec(open().read()) idiom is still a way to go,
there's a problem - it requires to load entire file to memory. But
there can be not enough memory. Consider 1Mb file with 900Kb comments
(autogenerated, for example). execfile() could easily parse it, using
small buffer. But exec() requires to slurp entire file into memory, and
1Mb is much more than heap sizes that we target.
Comments, suggestions? Just to set a productive direction, please
kindly don't consider the problems above as MicroPython's. I very much
liked how last discussion went: I was pointed that
https://docs.python.org/3/reference/index.html is not really a CPython
reference, it's a *Python* reference, and there were even motion to
clarify in it some points which came out from MicroPython discussion.
So, what about https://docs.python.org/3/library/index.html - is it
CPython, or Python standard library specification? Assuming the latter,
what we have is that, by removal of previously available feature,
*Python* became less friendly for interactive usage and less scalable.
Thanks,
Paul mailto:[email protected]
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Criticism of execfile() removal in Python3
On Tue, Jun 10, 2014 at 05:23:12AM +0300, Paul Sokolovsky wrote:
> execfile() builtin function was removed in 3.0. This brings few
> problems:
>
> 1. It hampers interactive mode - instead of short and easy to type
> execfile("file.py") one needs to use exec(open("file.py").read()).
If the amount of typing is the problem, that's easy to solve:
# do this once
def execfile(name):
exec(open("file.py").read())
Another possibility is:
os.system("python file.py")
> 2. Ok, assuming that exec(open().read()) idiom is still a way to go,
> there's a problem - it requires to load entire file to memory. But
> there can be not enough memory. Consider 1Mb file with 900Kb comments
> (autogenerated, for example). execfile() could easily parse it, using
> small buffer. But exec() requires to slurp entire file into memory, and
> 1Mb is much more than heap sizes that we target.
There's nothing stopping alternative implementations having their own
implementation-specific standard library modules.
steve@orac:/home/s$ jython
Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19)
[OpenJDK Server VM (Sun Microsystems Inc.)] on java1.6.0_27
Type "help", "copyright", "credits" or "license" for more information.
>>> import java
>>>
So you could do this:
from upy import execfile
execfile("file.py")
So long as you make it clear that this is a platform specific module,
and don't advertise it as a language feature, I see no reason why you
cannot do that.
--
Steven
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Criticism of execfile() removal in Python3
On 6/9/2014 11:03 PM, Steven D'Aprano wrote:
On Tue, Jun 10, 2014 at 05:23:12AM +0300, Paul Sokolovsky wrote:
execfile() builtin function was removed in 3.0.
Because it was hardly ever used. For short bits of code, it is usually
inferior to exec with a string in the file. For substantial bits of
code, it is generally inferior to 'from file import *' and does not have
the option of other forms of import. For startup code that you want
every session, it is inferior to PYTHONSTARTUP or custom site module.
>> This brings few problems:
1. It hampers interactive mode - instead of short and easy to type
execfile("file.py") one needs to use exec(open("file.py").read())
If the amount of typing is the problem, that's easy to solve:
# do this once
def execfile(name):
exec(open("file.py").read())
Another possibility is:
os.system("python file.py")
2. Ok, assuming that exec(open().read()) idiom is still a way to go,
there's a problem - it requires to load entire file to memory. But
there can be not enough memory. Consider 1Mb file with 900Kb comments
(autogenerated, for example). execfile() could easily parse it, using
small buffer. But exec() requires to slurp entire file into memory, and
1Mb is much more than heap sizes that we target.
Execfile could slurp the whole file into memory too. Next parse the
entire file. Then execute the entire bytecode. Finally toss the bytecode
so that the file has to be reparsed next time it is used.
There's nothing stopping alternative implementations having their own
implementation-specific standard library modules.
...
So you could do this:
from upy import execfile
execfile("file.py")
So long as you make it clear that this is a platform specific module,
and don't advertise it as a language feature, I see no reason why you
cannot do that.
If you want execfile as a substitute for 'python -i file' on the
unavailable command console, you should have the option to restore
globals to initial condition. Something like (untested)
# startup entries in globals in CPython 3.4.1
startnames={'__spec__', '__name__', '__builtins__',
'__doc__', '__loader__', '__package__'}
def execfile(file, encoding='utf-8', restart=):
glodict = globals()
code = open(file, 'r', encoding=encoding)
# don't restart if the file does not open
if restart:
for name in list(glodict):
if name not in startnames:
del glodict(name)
for statement in statements(code): # statements is statement iterator
exec(statement,...globals=glodict, locals=glodict)
--
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Returning Windows file attribute information via os.stat()
Hi folks, As pointed out to me recently in an issue report [1] on my scandir module, Python's os.stat() simply discards most of the file attribute information fetched via the Win32 system calls. On Windows, os.stat() calls CreateFile to open the file and get the dwFileAttributes value, but it throws it all away except the FILE_ATTRIBUTE_DIRECTORY and FILE_ATTRIBUTE_READONLY bits. See CPython source at [2]. Given that os.stat() returns extended, platform-specific file attributes on Linux and OS X platforms (see [3] -- for example, st_blocks, st_rsize, etc), it seems that Windows is something of a second-class citizen here. There are several questions on StackOverflow about how to get this information on Windows, and one has to resort to ctypes. For example, [4]. To solve this problem, what do people think about adding an "st_winattrs" attribute to the object returned by os.stat() on Windows? Then, similarly to existing code like hasattr(st, 'st_blocks') on Linux, you could write a cross-platform function to determine if a file was hidden, something like so: FILE_ATTRIBUTE_HIDDEN = 2 # constant defined in Windows.h def is_hidden(path): if startswith(os.path.basename(path), '.'): return True st = os.stat(path) if hasattr(st, 'st_winattrs') and st.st_winattrs & FILE_ATTRIBUTE_HIDDEN: return True return False I'd be interested to hear people's thoughts on this. Thanks, Ben. [1]: https://github.com/benhoyt/scandir/issues/22 [2]: https://github.com/python/cpython/blob/master/Modules/posixmodule.c#L1462 [3]: https://docs.python.org/3.4/library/os.html#os.stat [4]: http://stackoverflow.com/a/6365265 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Criticism of execfile() removal in Python3
On Mon, Jun 9, 2014 at 9:03 PM, Steven D'Aprano wrote: > ... > There's nothing stopping alternative implementations having their own > implementation-specific standard library modules. > > steve@orac:/home/s$ jython > Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19) > [OpenJDK Server VM (Sun Microsystems Inc.)] on java1.6.0_27 > Type "help", "copyright", "credits" or "license" for more information. > >>> import java > >>> > > Small nit: Jython does implement a number of implementation-specific modules in its version of the standard library; jarray comes to mind, which is mostly but not completely superseded by the standard array module. However, the java package namespace is not part of the standard library, it's part of the standard Java ecosystem and it's due to a builtin import hook: Jython 2.7b3+ (default:6cee6fef06f0, Jun 9 2014, 22:29:14) [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_60 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', '/home/jbaker/jythondev/jython27/dist/Lib', '__classpath__', '__pyclasspath__/', '/home/jbaker/.local/lib/jython2.7/site-packages', '/home/jbaker/jythondev/jython27/dist/Lib/site-packages'] The entry __classpath__ means search CLASSPATH for Java packages; this includes the Java runtime, rt.jar, from which you get package namespaces as java.*, javax.*, sun.*, etc. Another behavior that you get for free in Jython is being able to also import the org.python.* namespace, which is Jython's own runtime. Some of the implementations of standard library modules, such as threading, take advantage of this support. - Jim ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
