[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"
Mateusz Loskot added the comment: Possibly, the new partial-input mode of the parser (https://bugs.python.org/issue46521#msg412832) will improve this issue in 3.11. I'm going to play with it soon and I will report back. -- ___ Python tracker <https://bugs.python.org/issue46502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"
Mateusz Loskot added the comment: Not quite the answer I'd like to received, but thank you very much for the explanation. I've submitted pull request removing the deprecated FAQ entry https://github.com/python/cpython/pull/30925 -- ___ Python tracker <https://bugs.python.org/issue46502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"
Mateusz Loskot added the comment: Irit, I can and I will submit a patch. However, I'm very keen to learn what is an alternative solution then to distinguish hard invalid from incomplete input. IOW, what would be the new way of achieving what's described in the old FAQ? I believe it would be more useful to the community if I updated the sample in the FAQ instead of just removing it. -- ___ Python tracker <https://bugs.python.org/issue46502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46502] Py_CompileString no longer allows to tell "incomplete input" from "invalid input"
New submission from Mateusz Loskot : Something has changed in Python 3.7 through 3.10 (I'm observing it in 3.10) in behaviour of the Python C API function Py_CompileString such that for an incomplete input it no longer raises SyntaxError: "unexpected EOF while parsing" but IndentationError: expected an indented block after ... The new behaviour makes the sample program from the "How do I tell “incomplete input” from “invalid input”?" at https://docs.python.org/3/faq/extending.html no longer work as described there. For example: ``` for i in []: ``` raises IndentationError: expected an indented block after 'for' statement on line 1 ``` if True: ``` raises IndentationError: expected an indented block after 'if' statement on line 1 instead of SyntaxError: unexpected EOF while parsing This effectively makes it impossible to detect incomplete input using the Py_CompileString in applications where it is not possible to use PyRun_InteractiveLoop. I have failed to identify what could be related changes in the release notes and the documentation does not seem to offer any update on that. So, I'm assuming the new behaviour is not desired or expected. Attached, is the VS 2022 screenshot with debugging session of the sample program from the FAQ presenting the difference in the behaviour between Python 3.6 and 3.10 on Windows. -- components: C API files: Py_CompileString-Py36-vs-Py310.png messages: 411484 nosy: mloskot priority: normal severity: normal status: open title: Py_CompileString no longer allows to tell "incomplete input" from "invalid input" versions: Python 3.10 Added file: https://bugs.python.org/file50582/Py_CompileString-Py36-vs-Py310.png ___ Python tracker <https://bugs.python.org/issue46502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)
Change by Mateusz Loskot : -- nosy: +mloskot ___ Python tracker <https://bugs.python.org/issue39511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14597] Cannot unload dll in ctypes until script exits
Changes by Mateusz Loskot <mate...@loskot.net>: -- nosy: +mloskot ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: Re msg238016, I confirm python-3.5.0a2-fdvalidation.patch fixes the problem for Python 3.5.0a4 and VS2013. The only issue I encountered was with HAVE_FSTAT which is missing from PC/pyconifg.h, so I edited the patch and removed the check if defined(HAVE_FSTAT). Does PC/pyconifg.h need update? I also confirm vanilla Python 3.5.0a4 with VS2015RC does not require this patch, because the fileno regression/bug has been fixed in VS2015RC (details at https://connect.microsoft.com/VisualStudio/feedback/details/785119/). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17797 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: is_whatever_you_are_testing_for as method or property?
On 13 December 2014 at 12:24, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Mateusz Loskot wrote: On 12 December 2014 at 12:26, Chris Angelico ros...@gmail.com wrote: On Fri, Dec 12, 2014 at 10:21 PM, Mateusz Loskot mate...@loskot.net wrote: I've got several cases which are not obvious to me. For instance, class Foo has a boolean attribute, read-write, which I see a couple of realisations for possible: [...] I mentioned, setting the new value involves more changes to Foo() instance, so i's not possible to capture it with just an assignment. Hence, the discussion between property vs method. If the calculation is cheap and fast and feels like getting/setting an attribute, then use property. If the calculation is expensive, or might fail, then use explicit getter/setter methods. I'm afraid that there is no objective way to tell when something feels like an attribute. That depends partly on the class you are dealing with, and partly on personal taste. That confirms my now updated, thanks to this thread, understanding of that issue. Thanks all! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- https://mail.python.org/mailman/listinfo/python-list
Re: is_whatever_you_are_testing_for as method or property?
On 11 December 2014 at 19:20, Chris Angelico ros...@gmail.com wrote: On Fri, Dec 12, 2014 at 4:34 AM, Mateusz Loskot mate...@loskot.net wrote: If a class member function simply tests something and returns a b::oolean call it def is_whatever_you_are_testing_for(): pass like 'is_even'. Should I define it as a classic method def is_even(self): pass or as a property @property def is_even(self): pass A property should be used if what you're creating is virtually an attribute. If it would make sense to have an attribute is_even, then a property is_even makes sense. If in doubt, go with a method. Thanks for the advise. I've got several cases which are not obvious to me. For instance, class Foo has a boolean attribute, read-write, which I see a couple of realisations for possible: 1) properties only class Foo: @property def is_default(self): pass @is_default.setter def is_default(self, current): pass 2) property + method mix class Foo: @property def is_default(self): pass def make_default(self, current): pass 3) methods only class Foo: def is_default(self): pass def make_default(self, current): pass From one angle, that is is_default is known and does not need to be calculated upon every query, the option 1) fits well. It is aligned with Ethan's suggestion in the other post. From other point, let's assume updating it takes a little bit of changes of state of Foo instance, then perhaps methods-only option 3) fits best. Looks like if in doubt, go with a method is the safest bet. 'Statistics' from Python codebase also seem to suggest that. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- https://mail.python.org/mailman/listinfo/python-list
Re: is_whatever_you_are_testing_for as method or property?
On 12 December 2014 at 12:26, Chris Angelico ros...@gmail.com wrote: On Fri, Dec 12, 2014 at 10:21 PM, Mateusz Loskot mate...@loskot.net wrote: I've got several cases which are not obvious to me. For instance, class Foo has a boolean attribute, read-write, which I see a couple of realisations for possible: 0) Attribute only. class Foo: pass Foo().default = True Unless you need something more than this, go with this style. Much simpler. Agreed, in general, but if the question was related to such simple case, I wouldn't bother asking it. I mentioned, setting the new value involves more changes to Foo() instance, so i's not possible to capture it with just an assignment. Hence, the discussion between property vs method. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- https://mail.python.org/mailman/listinfo/python-list
Re: is_whatever_you_are_testing_for as method or property?
On 12 December 2014 at 22:14, Chris Angelico ros...@gmail.com wrote: On Sat, Dec 13, 2014 at 8:03 AM, Mateusz Loskot mate...@loskot.net wrote: On 12 December 2014 at 12:26, Chris Angelico ros...@gmail.com wrote: On Fri, Dec 12, 2014 at 10:21 PM, Mateusz Loskot mate...@loskot.net wrote: I've got several cases which are not obvious to me. For instance, class Foo has a boolean attribute, read-write, which I see a couple of realisations for possible: 0) Attribute only. class Foo: pass Foo().default = True Unless you need something more than this, go with this style. Much simpler. Agreed, in general, but if the question was related to such simple case, I wouldn't bother asking it. I mentioned, setting the new value involves more changes to Foo() instance, so i's not possible to capture it with just an assignment. Hence, the discussion between property vs method. It's still worth mentioning, for completeness. Of course, very good point. Plenty of people come from C++ That's me. or Java and simply don't realize that direct attribute access makes fine sense. Your statement here talks about a read-write boolean attribute, so starting off with the simplest way of doing that - an actual attribute - emphasizes the commonness of this. Yes, I see your point now. So, your subsequent design decisions are based around the fact that you cannot simply assign to .default and have it do the right thing. Are you even able to set default to False? Right. The particular case (with is_default and make_default members) I'm discussing is similar to this: class Window: def close(self): # operate window so it gets closed @property def is_closed(self) # query state of window For instance, you might have a system where there must always be one default, and so you can't make this one not-default, but you could make a different one the default, which will un-default-ify this one as a side effect. In that case, a make_default() method makes the most sense. But if you can independently and cheaply set any instance's default flag, you could have the actual attribute, and then a set_default() method, which updates it. Plenty of Python classes recommend not arbitrarily altering certain attributes. Yes, makes sense. Thanks for brainstorming those ideas deeper. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- https://mail.python.org/mailman/listinfo/python-list
is_whatever_you_are_testing_for as method or property?
Hi, I have been looking at various places to answer this dilemma: If a class member function simply tests something and returns a b::oolean call it def is_whatever_you_are_testing_for(): pass like 'is_even'. Should I define it as a classic method def is_even(self): pass or as a property @property def is_even(self): pass The question above is based on similar question I found [1], but that one is specifically about naming. I'm trying to solve the aspect of implementation of such predicate. I've looked into the Python 3.4 libs and most of such functions is realised as a classic method, but in several cases they are defined with @property decorator, for example: email.message.MIMEPart.iis_attachment ipaddress._BaseNetwork.is_multicast ipaddress._BaseNetwork is_reserved and a few more. So, a classic method or a property, which one is the Pythonic 3 way for such member predicates? [1] *Naming Conventions* by Thorsten Kampe https://mail.python.org/pipermail/python-list/2007-June/438156.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- https://mail.python.org/mailman/listinfo/python-list
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: FYI, I've got it confirmed fix for the bug in VS has been released [1] We have fixed this behavior for the next major release, Visual Studio 14. The fix is present in the Visual Studio 14 CTP that was released earlier this month. [1] https://connect.microsoft.com/VisualStudio/feedback/details/785119/fileno-stdin-0-for-non-console-application#tabs -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17797 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21452] make_buildinfo.exe with VS2013 fails due ill-formed IntDir path
New submission from Mateusz Loskot: While building Python 3.2 or Python 3.4 with Visual Studio 2013 on Windows 8.1, pythoncore.vcxproj fails to build due to illformed pre-link event command. (FYI, I have upgraded all .vcxproj files to VS2013 locally.) Here is the command and the error: pre 1PreLinkEvent: 1 Description: Generate build information... 1 cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd ..\Modules\getbuildinfo.c -FoD:\tmp\Python-3.4.0-vs2013\PCbuild\Win32-temp-Debug\pythoncore \getbuildinfo.o -I..\Include -I..\PC 1 getbuildinfo.c 1..\Modules\getbuildinfo.c(1): fatal error C1083: Cannot open include file: 'Python.h': No such file or directory /pre Notice the superfluous double quote followed by whitespace in the following argument: pre -FoD:\tmp\Python-3.4.0-vs2013\PCbuild\Win32-temp-Debug\pythoncore \getbuildinfo.o /pre The problem is somewhat known as there is related comment in the make_buildinfo.c file about the custom commands arguments parsing: pre /* Hack fix for bad command line: If the command is issued like this: * $(SolutionDir)make_buildinfo.exe Debug $(IntDir) * we will get a trailing quote because IntDir ends with a backslash that then * escapes the final . To simplify the life for developers, catch that problem * here by cutting it off. * The proper command line, btw is: * $(SolutionDir)make_buildinfo.exe Debug $(IntDir)\ * Hooray for command line parsing on windows. */ /pre There are two solutions possible: 1) Correct the PreLinkEvent command in make_buildinfo.vcxproj according to the comment above: pre $(SolutionDir)make_buildinfo.exe Debug $(IntDir)\ /pre 2) Patch make_buildinfo.c (attached). Then, the cl.exe command is correct: pre 1 cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd ..\Modules\getbuildinfo.c -FoF:\V81-VS2013.win32\Librarie s\External\Source\Python\Debug\PCbuild\Win32-temp-Debug\pythoncore\getbuildinfo.o -I..\Include -I..\PC 1 getbuildinfo.c /pre I'm not sure why this problems leaks while building with VS2013. I have been building Python 3.2 with VS2012 for long time w/o any issues. Perhaps, it is related to combination of VS2013 and Windows 8.1. Although, I'm not observing this problem while building with VS2012 on Windows 8.1, it would be helpful if someone else who uses VS2012 or VS2013 could confirm my results. -- components: Build files: Python340-make_buildinfo-vs2013.patch keywords: patch messages: 218097 nosy: mloskot priority: normal severity: normal status: open title: make_buildinfo.exe with VS2013 fails due ill-formed IntDir path type: compile error versions: Python 3.2, Python 3.4 Added file: http://bugs.python.org/file35183/Python340-make_buildinfo-vs2013.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21452 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment:
I have just tested Windows GUI application built against Python 3.2.1 with
is_valid_fd patch according to http://hg.python.org/cpython/rev/f15943505db0/
All built using VS2012.
Again, I can confirm that is_valid_fd does NOT solve the problem.
Here is extract of execution flow in initstdio function:
1. fd = 0, despite it is GUI app, see
https://connect.microsoft.com/VisualStudio/feedback/details/785119/
fd = fileno(stdin);
2. is_valid_fd will return __true__, so it moves to calling create_stdio()
if (!is_valid_fd(fd)) {
...
}
else {
std = create_stdio(iomod, fd, 0, stdin, encoding, errors);
if (std == NULL)
goto error;
}
3. The create_stdio() call fails though, causing error followed by abort
Still, the only solution that solves this problem in Windows GUI applications
buitl using VS2012 is to use check_fd() function to check fd, instead of
is_valid_fd(). The check_fd() is more reliable as it will return -1 due to
errno == EBADF.
My previous attempt to analyse _PyVerify_fd() is not relevant for the problem,
let's forget it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17797
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: @Antoine (Re msg197480) I'm not sure which minor version of Python 3.2 it was, but in my comment in msg187362, I confirmed that I have tested the later version with added is_valid_fd function. As far as I understand, the changes in http://hg.python.org/cpython/rev/f15943505db0/ introduce that is_valid_fd function, which does not seem to solve the problem. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17797 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: On 11 September 2013 12:34, Antoine Pitrou rep...@bugs.python.org wrote: I'm not sure which minor version of Python 3.2 it was, but in my comment in msg187362, I confirmed that I have tested the later version with added is_valid_fd function. As far as I understand, the changes in http://hg.python.org/cpython/rev/f15943505db0/ introduce that is_valid_fd function, which does not seem to solve the problem. Could you try to investigate this a bit further? Does is_valid_fd() return true, and why? I have already checked that (see msg187362) Shortly, is_valid_fd always returns true because fd 0 is always false as my tests with Visual Studio 2012 (Visual C++ 11.0 (1700) confirmed (see also bug report linked in msg188117) assert(fdi == 0); assert(fdo == 1); assert(fde == 2); IOW, fd is always larger than 0. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17797 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment:
On 12 September 2013 00:06, Antoine Pitrou rep...@bugs.python.org wrote:
Shortly, is_valid_fd always returns true because fd 0 is always
false as my tests with Visual Studio 2012
Well, that's not all there is, is_valid_fd() does other checks before
returning true.
Given the function:
is_valid_fd(int fd)
{
int dummy_fd;
if (fd 0 || !_PyVerify_fd(fd))
return 0;
dummy_fd = dup(fd);
if (dummy_fd 0)
return 0;
close(dummy_fd);
return 1;
}
for fd values of 0, 1 or 2
1. fd 0 is always false
2. _PyVerify_fd(fd) is always true. Given the current definition:
#define _PyVerify_fd(fd) (_get_osfhandle(fd) = 0)
for those values of fd _get_osfhandle(fd) = 0, always.
3. for those fd values, dup() never returns fd 0
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17797
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: This is still an issue in VS 2012 Version 11.0.60610.01 Update 3 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17797 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: I've just got an update on the bug report [1] I submitted to Microsoft. The Visual C++ team confirmed It does appear to be a regression from Visual Studio 2010. So, it's not a bug in Python, but I think it may be important for Python to consider applying some reliable workaround (i.e. use of check_fd() function) [1] http://connect.microsoft.com/VisualStudio/feedback/details/785119/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17797 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
New submission from Mateusz Loskot:
In pythonrun.c, there is function initstdio() with the following test:
static int
initstdio(void)
{
...
/* Set sys.stdin */
fd = fileno(stdin);
/* Under some conditions stdin, stdout and stderr may not be connected
* and fileno() may point to an invalid file descriptor. For example
* GUI apps don't have valid standard streams by default.
*/
if (fd 0) {
#ifdef MS_WINDOWS
std = Py_None;
Py_INCREF(std);
#else
goto error;
#endif
}
else {
...
}
This function is fails for non-console applications (i.e. MFC) built using
Visual C++ 11.0 (Visual Studio 2012), becasue **strangely**, fileno(stdin) ==
0, so this test results in false and Python initialisation routines attempt to
setup streams.
Apparently, fileno(stdin) return value has changed between Visual C++ 10.0 (VS
2010)
and 11.0. The VC++ 10.0 reports fileno(stdin) == -2.
--
components: IO, Interpreter Core
messages: 187351
nosy: mloskot
priority: normal
severity: normal
status: open
title: Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17797
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment:
Yes, it does. In file Modulfileio.c, in function fileio_init, there is this
code:
if (fd = 0) {
if (check_fd(fd))
goto error;
self-fd = fd;
self-closefd = closefd;
}
The check_fd tests:
if (!_PyVerify_fd(fd) || (fstat(fd, buf) 0 errno == EBADF)) {
The _PyVerify_fd(fd) == 1, but errno is Bad file descriptor.
This eventually leads to Py_InitializeEx failure at:
if (initstdio() 0)
Py_FatalError(
Py_Initialize: can't initialize sys standard streams);
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17797
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: In file Modulfileio.c, I messed the path and filename above I meant: In file Modules/_io/fileio.c, -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17797 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Mateusz Loskot added the comment: Replacing if the current test in Python 3.2 if (fd 0) with if (check_fd(fd) 0) Seems to be a working solution. I just noticed, that in current Python/pythonrun.c in the repo, there the fd 0 tests have been replaced with new function is_valid_fd(). But, its semantic is equivalent to fd 0, so it does not check anything really. Perhaps is_valid_fd could be redefined as check_fd. Here are Visual C++ 11.0 (1700) vs 10.0 differences of fileno return value for all the standard streams int fdi, fdo, fde; fdi = fileno(stdin); fdo = fileno(stdout); fde = fileno(stderr); #if _MSC_VER 1700 assert(fdi == -2); assert(fdo == -2); assert(fde == -2); #else assert(fdi == 0); assert(fdo == 1); assert(fde == 2); #endif By the way, I assume such sudden change in fileno(std*) behaviour between Visual C++ versions is suspicious, so I also submitted bug report to Visual Studio: https://connect.microsoft.com/VisualStudio/feedback/details/785119/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17797 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Fwd: Format of datetime dump
Hi,
I'm not sure if this list is the right place to ask question about PyYAML,
but the yaml-core seems to be too general and quiet.
So, I decided to forward my question here.
I asked on yaml-core the following question, would anyone have any insights?
Mat
-- Forwarded message --
From: Mateusz Loskot mate...@loskot.net
Date: 19 October 2012 13:58
Subject: Format of datetime dump
To: yaml-c...@lists.sourceforge.net
Hi,
Given this snippet:
yaml.dump({'date':datetime.datetime.now()})
{date: !!timestamp '2012-10-19 01:32:41.674322'}\n
Could anyone enlighten me why the ISO8601 format -MM-DDThh:mm:ssTZD
is not used here, by default?
Is there any mean to make yaml.dump generating datetime in ISO8601?
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--
Mateusz Loskot, http://mateusz.loskot.net
--
http://mail.python.org/mailman/listinfo/python-list
[issue4442] document immutable type subclassing via __new__
Mateusz Loskot mate...@loskot.net added the comment: Chris Withers' note clarifies it to me, that this should be Python-level rather than C-level documentation. Then the note under __new__() in 3. Data model seems right. Simply, I expected to have some notes in C API too Side note: as mainly Python C API user, I expected to have it documented at C API level too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4442 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4442] document immutable type subclassing via __new__
Changes by Mateusz Loskot mate...@loskot.net: -- nosy: +mloskot ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4442 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4442] document immutable type subclassing via __new__
Mateusz Loskot mate...@loskot.net added the comment: Is this report about documenting of the concept of immutable types in Python in general or regarding existing built-in types, like datetime.datetime? Generally, the concept of immutable type with relation to tp_new is mentioned (sneaked) here: 1) http://docs.python.org/release/3.2.2/c-api/typeobj.html A good rule of thumb is that for immutable types, all initialization should take place in tp_new, while for mutable types, most initialization should be deferred to tp_init. 2) http://www.python.org/dev/peps/pep-0253/ Note that for immutable object types, the initialization cannot be done by the tp_init() slot: this would provide the Python user with a way to change the initialization. Therefore, immutable objects typically have an empty tp_init() implementation and do all their initialization in their tp_new() slot. IMHO, it deserves a dedicated section/chapter in the docs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4442 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15029] Update Defining New Types chapter according to PEP 253
New submission from Mateusz Loskot mate...@loskot.net: The chapter '2. Defining New Types in the Python 3.2 documentation [1] does not cover all important elements, especially in the subsection 2.1.4. Subclassing other types. The accepted PEP 253 [2] provides much more detailed and thorough explanation for Python C API users willing to define and subclass new types, than the official manual. I'd like to suggest update of the manual with information enclosed in the PEP 253. In fact, the PEP's sections like * Preparing a type for subtyping * Creating a subtype of a built-in type in C could be copied with little editing, IMHO. The PEP 253 really seems to be a must-read document for Python C API users. [1] http://docs.python.org/release/3.2.2/extending/newtypes.html [2] http://www.python.org/dev/peps/pep-0253/ -- assignee: docs@python components: Documentation messages: 162480 nosy: docs@python, mloskot priority: normal severity: normal status: open title: Update Defining New Types chapter according to PEP 253 type: enhancement versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15029] Update Defining New Types chapter according to PEP 253
Mateusz Loskot mate...@loskot.net added the comment: Similar request has been rejected in response to the Issue 621526 [1], but I'm not proposing to include PEP into docs, but to update and improve docs with material discussed in accepted PEPs. [1] http://bugs.python.org/issue621526 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue621526] docs do not include spec info from PEPs
Mateusz Loskot mate...@loskot.net added the comment: I reported issue 15029 [1] which may be related to this one. [1] http://bugs.python.org/issue15029 -- nosy: +mloskot ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue621526 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Read-only attribute in module
Hi, I'm implementing Python 3 extension using the Python C API. I am familiar with defining new types, implementing get/set for attributes, etc. I'm wondering, is there any mean to implement attribute in module scope which is read-only? So, the following import xyz print(xyz.flag) # OK xyz.flag = 0# error due to no write access Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- http://mail.python.org/mailman/listinfo/python-list
How do I tell incomplete input from invalid input?
Hi,
I have been trying to figure out a reliable way to determine
incomplete Python script
input using Python C API. (Apology if it is OT here, I'm not sure where my post
belongs, perhaps to cplusplus-sig list.)
Apparently, most pointers lead to the Python FAQ [1] question:
How do I tell incomplete input from invalid input?
Unfortunately, this FAQ is either old or incomplete thus incorrect.
First, the proposed testcomplete() function uses internal symbols
which are not available to Python C API users. So, whoever wrote that FAQ
should be given 20 lashes with a short piece of string [2].
The second solution is incomplete or incorrect. It does not handle correctly
multi-line input longer than two lines with more flow control statements.
For example:
##
n = 10
if n 0:
...if n 100:
File stdin, line 2
if n 100:
^
IndentationError: expected an indented block
##
or
##
for n in range(0, 5):
... if n 2:
File stdin, line 2
if n 2:
^
IndentationError: expected an indented block
##
I have attached a slightly modified C++ version of the second program
from the FAQ question [1],
file faq_incomplete_input.cpp which is also available from my GitHub repo [3]
In this program, I added several FIX comments with proposed corrections.
The idea is to additionally check for
PyErr_ExceptionMatches (PyExc_IndentationError)
and
strcmp (msg, expected an indented block)
and
prompt is sys.ps2, means more code expected.
And, ignore errors until user confirms the input is finished,
so the whole input is eventually sent to the Py_CompileString
and then all exceptions are not ignored, but considered
as real result of compilation.
I simply wanted to achieve similar semantic to codeop._maybe_compile()
(called by codeop.compile_command) which performs some sort of dirty
hack in the following line:
if not code1 and repr(err1) == repr(err2):
So, the test in action for multi-line multi-statement input gives:
##
c = codeop.compile_command(for n in range(0, 3):, test, single)
err1 SyntaxError('unexpected EOF while parsing', ('test', 1, 22, 'for
n in range(0, 3):\n'))
err2 IndentationError('expected an indented block', ('test', 2, 1, '\n'))
comparison.err1 SyntaxError('unexpected EOF while parsing', ('test',
1, 22, 'for n in range(0, 3):\n'))
comparison.err2 IndentationError('expected an indented block',
('test', 2, 1, '\n'))
code None
code1 None
c = codeop.compile_command(for n in range(0, 3):\n\tif n 0:, test,
single)
err1 IndentationError('expected an indented block', ('test', 2, 11,
'\tif n 0:\n'))
err2 IndentationError('expected an indented block', ('test', 3, 1, '\n'))
comparison.err1 IndentationError('expected an indented block',
('test', 2, 11, '\tif n 0:\n'))
comparison.err2 IndentationError('expected an indented block',
('test', 3, 1, '\n'))
code None
code1 None
##
So, I reckon it make sense to use the same logic to when calling
Py_CompileString.
Does it sound as reasonable solution?
Basically, there seem to be no canonical solution anywhere presented
on how to perform incomplete input tests in reliable manner, how to perform
parsing/compilation in subsequent steps against Python code given line-by-line.
The C API used by Python function compile() is not publicly available.
There is PyRun_InteractiveLoop mechanism but it is tightly coupled to
FILE-based I/O which is not always available when Python is embedded,
so the loop is useless in number of situations.
Have I overlooked any other obvious solution?
Finally, it would be helpful if the Python FAQ is up to date.
[1]
http://docs.python.org/py3k/faq/extending.html#how-do-i-tell-incomplete-input-from-invalid-input
[2] http://mail.python.org/pipermail/python-list/2004-August/887195.html
[3] https://github.com/mloskot/workshop/blob/master/python/
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
//
// A quick and dirty C++ version of the C program presented in Python FAQ:
// http://docs.python.org/py3k/faq/extending.html#how-do-i-tell-incomplete-input-from-invalid-input
// Modifications:
// - do not use readline library, but iostream
//
// Tested using Visual C++ 2010 (10.0) and Python 3.2 (custom Debug build)
//
// The incomplete input solution presented in the FAQ is incomplete and it does
// not allow multi-line scripts with more than 2 lines of flow control statements:
//
// n = 10
// if n 0:
//... if n 100:
// File stdin, line 2
//if n 100:
// ^
//IndentationError: expected an indented block
//
//
// n = 10
// if n 0:
//... if n
Re: PyEval_EvalCodeEx return value
John Pinner-3 wrote: I assume that you have read the documentation at http://docs.python.org/c-api/veryhigh.html, and I agree that it's sparse, but the entry for the next entry, PyEval_EvalCodeEx, tells you a little more, as does that for PyEval_EvalFrameEx. It does help, but only a bit. John Pinner-3 wrote: Obviously, it's returning a pointer to a PyObject, and Looking at the source code, that may be NULL, to throw an exception, or an execution frame, or a generator,etc, etc, depending on the code it's been given. I guess that you should be able to inspect the PyObject to see what it is. Yes, that's one possibility. I tried to investigate others. John Pinner-3 wrote: What I'm wondering is, why are you eval-ing code ? A favourite device of C programmers coming to Python (and mea culpa in the past), it's fraught with potential problems and even security risks, and is difficult to debug, and maybe you should be using introspection instead. My application accepts Python scripts from user and executes using embedded Python interpreter. So, I use this particular API. Could you elaborate on the using introspection? John Pinner-3 wrote: And maybe you should be working in Python, and not C++ at this point, do the dynamic stuff in the language best suited, and then return to C++ when needed. My application in C++ interacts with Python programs provided by users. Depending on what these programs request, various PyObject objects are created and returned back, etc. I understand it's difficult to discuss it without long essays or without providing the code, etc. So, I can only discuss and investigate building blocks I use. Anyway, thanks for your comments. Best regards, - -- Mateusz Loskot http://mateusz.loskot.net -- View this message in context: http://old.nabble.com/PyEval_EvalCodeEx-return-value-tp32501833p32503908.html Sent from the Python - python-list mailing list archive at Nabble.com. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyEval_EvalCodeEx return value
On 23/09/11 00:47, Mark Hammond wrote: On 20/09/2011 8:34 PM, Mateusz Loskot wrote: I'm trying to dig out details about what exactly is the return value the of PyEval_EvalCodeEx function in Python 3.x The documentation is sparse, unfortunately. Perhaps I'm looking at wrong function. My aim is simple, I need to execute Python code using Python interpreter embedded in my C++ application. The Python code is a simple script that always returns single value. For example: #! /usr/bin/env python def foo(a, b): return a + b f = foo(2, 3) But, f can be of different type for different script: one returns numeric value, another returns a sequence, so the type is not possible to be determined in advance. I know how to capture Python stdout/stderr. I also know how to access the f attribute using PyObject_GetAttrString and then I can convert f value to C++ type depending on PyObject type. However, I guess there shall be a way to access f value directly from PyEval_EvalCode return object: PyObject* evalRet = ::PyEval_EvalCode(...); But, I can't find any details what the evalRet actually is. Eval is to eval an expression. If you simply eval the expression f in the context of the module you should get the result returned. Obviously though it is designed to eval more complex expressions and in your specific example, doing the getattr thing will also work fine. Hi Mark, So, the result of PyEval_EvalCode strictly depends on the code being evaluated. It makes sense. Thanks for help! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- http://mail.python.org/mailman/listinfo/python-list
PyEval_EvalCodeEx return value
Hi, I'm trying to dig out details about what exactly is the return value the of PyEval_EvalCodeEx function in Python 3.x The documentation is sparse, unfortunately. Perhaps I'm looking at wrong function. My aim is simple, I need to execute Python code using Python interpreter embedded in my C++ application. The Python code is a simple script that always returns single value. For example: #! /usr/bin/env python def foo(a, b): return a + b f = foo(2, 3) But, f can be of different type for different script: one returns numeric value, another returns a sequence, so the type is not possible to be determined in advance. I know how to capture Python stdout/stderr. I also know how to access the f attribute using PyObject_GetAttrString and then I can convert f value to C++ type depending on PyObject type. However, I guess there shall be a way to access f value directly from PyEval_EvalCode return object: PyObject* evalRet = ::PyEval_EvalCode(...); But, I can't find any details what the evalRet actually is. Any pointers would be helpful. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- http://mail.python.org/mailman/listinfo/python-list
Why PyImport_ExecCodeModule takes char*?
Hi, I'm wondering, why PyImport_ExecCodeModule function takes char* instead of const char*? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- http://mail.python.org/mailman/listinfo/python-list
