Re: [Python-Dev] r84388 - in python/branches/py3k/Doc: conf.py using/index.rst
Am 01.09.2010 23:43, schrieb Nick Coghlan: On Thu, Sep 2, 2010 at 7:25 AM, Georg Brandl g.bra...@gmx.net wrote: That title isn't better though, since it doesn't cover the using/cmdline document which deals with command line options, environment variables and the like. I agree that Using Python is not very descriptive though. Python Setup and Usage? I'll change to that unless something better comes up :) 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Hi Victor,
1. This function and PyUnicode_strcat are missing documentation.
2. Are you sure they need to be public APIs? What are they going to
be used for? (I'm not sure myself, but I think we usually have a
short notice here when new C APIs are added.)
Georg
Am 02.09.2010 01:43, schrieb victor.stinner:
Author: victor.stinner
Date: Thu Sep 2 01:43:53 2010
New Revision: 84430
Log:
Create PyUnicode_strdup() function
Modified:
python/branches/py3k/Include/unicodeobject.h
python/branches/py3k/Objects/unicodeobject.c
Modified: python/branches/py3k/Include/unicodeobject.h
==
--- python/branches/py3k/Include/unicodeobject.h (original)
+++ python/branches/py3k/Include/unicodeobject.h Thu Sep 2 01:43:53 2010
@@ -220,6 +220,7 @@
# define _PyUnicode_AsDefaultEncodedString
_PyUnicodeUCS2_AsDefaultEncodedString
# define _PyUnicode_Fini _PyUnicodeUCS2_Fini
# define _PyUnicode_Init _PyUnicodeUCS2_Init
+# define PyUnicode_strdup PyUnicodeUCS2_strdup
#else
@@ -302,7 +303,7 @@
# define _PyUnicode_AsDefaultEncodedString
_PyUnicodeUCS4_AsDefaultEncodedString
# define _PyUnicode_Fini _PyUnicodeUCS4_Fini
# define _PyUnicode_Init _PyUnicodeUCS4_Init
-
+# define PyUnicode_strdup PyUnicodeUCS4_strdup
#endif
@@ -1602,6 +1603,14 @@
Py_UNICODE c
);
+/* Create a copy of a unicode string ending with a nul character. Return NULL
+ and raise a MemoryError exception on memory allocation failure, otherwise
+ return a new allocated buffer (use PyMem_Free() to free the buffer). */
+
+PyAPI_FUNC(Py_UNICODE*) PyUnicode_strdup(
+PyObject *unicode
+);
+
#ifdef __cplusplus
}
#endif
Modified: python/branches/py3k/Objects/unicodeobject.c
==
--- python/branches/py3k/Objects/unicodeobject.c (original)
+++ python/branches/py3k/Objects/unicodeobject.c Thu Sep 2 01:43:53 2010
@@ -10014,6 +10014,28 @@
return NULL;
}
+Py_UNICODE*
+PyUnicode_strdup(PyObject *object)
+{
+PyUnicodeObject *unicode = (PyUnicodeObject *)object;
+Py_UNICODE *copy;
+Py_ssize_t size;
+
+/* Ensure we won't overflow the size. */
+if (PyUnicode_GET_SIZE(unicode) ((PY_SSIZE_T_MAX / sizeof(Py_UNICODE))
- 1)) {
+PyErr_NoMemory();
+return NULL;
+}
+size = PyUnicode_GET_SIZE(unicode) + 1; /* copy the nul character */
+size *= sizeof(Py_UNICODE);
+copy = PyMem_Malloc(size);
+if (copy == NULL) {
+PyErr_NoMemory();
+return NULL;
+}
+memcpy(copy, PyUnicode_AS_UNICODE(unicode), size);
+return copy;
+}
#ifdef __cplusplus
}
--
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Georg Brandl wrote:
Hi Victor,
1. This function and PyUnicode_strcat are missing documentation.
2. Are you sure they need to be public APIs? What are they going to
be used for? (I'm not sure myself, but I think we usually have a
short notice here when new C APIs are added.)
If you want to make this a public API function, it also needs to be
renamed to fit the rest of the API.
I'd suggest PyUnicode_AsUnicodeCopy() which then corresponds
to PyUnicode_FromUnicode(), but I'm not sure whether we should
have such a public API in the first place.
Georg
Am 02.09.2010 01:43, schrieb victor.stinner:
Author: victor.stinner
Date: Thu Sep 2 01:43:53 2010
New Revision: 84430
Log:
Create PyUnicode_strdup() function
Modified:
python/branches/py3k/Include/unicodeobject.h
python/branches/py3k/Objects/unicodeobject.c
Modified: python/branches/py3k/Include/unicodeobject.h
==
--- python/branches/py3k/Include/unicodeobject.h (original)
+++ python/branches/py3k/Include/unicodeobject.h Thu Sep 2 01:43:53 2010
@@ -220,6 +220,7 @@
# define _PyUnicode_AsDefaultEncodedString
_PyUnicodeUCS2_AsDefaultEncodedString
# define _PyUnicode_Fini _PyUnicodeUCS2_Fini
# define _PyUnicode_Init _PyUnicodeUCS2_Init
+# define PyUnicode_strdup PyUnicodeUCS2_strdup
#else
@@ -302,7 +303,7 @@
# define _PyUnicode_AsDefaultEncodedString
_PyUnicodeUCS4_AsDefaultEncodedString
# define _PyUnicode_Fini _PyUnicodeUCS4_Fini
# define _PyUnicode_Init _PyUnicodeUCS4_Init
-
+# define PyUnicode_strdup PyUnicodeUCS4_strdup
#endif
@@ -1602,6 +1603,14 @@
Py_UNICODE c
);
+/* Create a copy of a unicode string ending with a nul character. Return
NULL
+ and raise a MemoryError exception on memory allocation failure, otherwise
+ return a new allocated buffer (use PyMem_Free() to free the buffer). */
+
+PyAPI_FUNC(Py_UNICODE*) PyUnicode_strdup(
+PyObject *unicode
+);
+
#ifdef __cplusplus
}
#endif
Modified: python/branches/py3k/Objects/unicodeobject.c
==
--- python/branches/py3k/Objects/unicodeobject.c (original)
+++ python/branches/py3k/Objects/unicodeobject.c Thu Sep 2 01:43:53 2010
@@ -10014,6 +10014,28 @@
return NULL;
}
+Py_UNICODE*
+PyUnicode_strdup(PyObject *object)
+{
+PyUnicodeObject *unicode = (PyUnicodeObject *)object;
+Py_UNICODE *copy;
+Py_ssize_t size;
+
+/* Ensure we won't overflow the size. */
+if (PyUnicode_GET_SIZE(unicode) ((PY_SSIZE_T_MAX /
sizeof(Py_UNICODE)) - 1)) {
+PyErr_NoMemory();
+return NULL;
+}
+size = PyUnicode_GET_SIZE(unicode) + 1; /* copy the nul character */
+size *= sizeof(Py_UNICODE);
+copy = PyMem_Malloc(size);
+if (copy == NULL) {
+PyErr_NoMemory();
+return NULL;
+}
+memcpy(copy, PyUnicode_AS_UNICODE(unicode), size);
+return copy;
+}
#ifdef __cplusplus
}
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Sep 02 2010)
Python/Zope Consulting and Support ...http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2010-08-19: Released mxODBC 3.1.0 http://python.egenix.com/
2010-09-15: DZUG Tagung, Dresden, Germany 12 days to go
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Buffer protocol for io.BytesIO?
Hello all, In issue #5506, I originally proposed that io.BytesIO objects support the buffer protocol, to make it possible to access the internal buffer without intermediate copies. Then it came to me then perhaps it would be too automatic. So I'm currently floating between: - add implicit buffer protocol support to BytesIO objects - add explicit buffer protocol support through the call of a getbuffer() method, which would return a small intermediate object supporting the buffer protocol on behalf of the original BytesIO object What do you think would be better? Thank you Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
On Thu, Sep 2, 2010 at 6:51 PM, Georg Brandl g.bra...@gmx.net wrote: Hi Victor, 1. This function and PyUnicode_strcat are missing documentation. 2. Are you sure they need to be public APIs? What are they going to be used for? (I'm not sure myself, but I think we usually have a short notice here when new C APIs are added.) I believe I first saw them on Victor's branch for improved Unicode support (especially in the context of import). I agree that private _Py prefixes are probably a better idea here. The public API should focus on Py_Unicode, with only a minimal collection of Py_UNICODE interfaces. Regarding the naming scheme, if these are what I recall them as (drop in replacements for the 8-bit C stdlib equivalents to simplify the relevant import.c updates), I'm fine with the current naming for private API functions, but agree with MAL they should be made more explicit if they're part of the published API. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buffer protocol for io.BytesIO?
On Fri, Sep 3, 2010 at 6:35 AM, Antoine Pitrou solip...@pitrou.net wrote: Hello all, In issue #5506, I originally proposed that io.BytesIO objects support the buffer protocol, to make it possible to access the internal buffer without intermediate copies. Then it came to me then perhaps it would be too automatic. So I'm currently floating between: - add implicit buffer protocol support to BytesIO objects - add explicit buffer protocol support through the call of a getbuffer() method, which would return a small intermediate object supporting the buffer protocol on behalf of the original BytesIO object What do you think would be better? The latter offers an easy future upgrade path if we decide that implicit would be better (i.e. change getbuffer() to just return self). If we go straight to implicit there's no easy way back to the explicit version. I think getbuffer() also parallels getvalue() quite well. Call it +1 for explicit and -0 for implicit. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 status
On Wed, Sep 1, 2010 at 10:54 PM, Antoine Pitrou solip...@pitrou.net wrote: Please consider this: even without relying on PEP 384, using FILE* is /already/ dangerous; because you might compile an extension with a different compiler version than Python was compiled with. So, if we were following you, we should rip out PyObject_Print() of the whole C API, not only the limited subset which is defined by PEP 384. (now I have nothing against completely ripping out PyObject_Print() if we find out that it's not really useful...) I finally took the obvious step of grepping the include directory to see what APIs were even affected by this question. Turns out there are more APIs than I thought, but most extension modules aren't going to need most of them (since they're related to code parsing, compilation and execution directly from files). For the remainder, I propose as a starting point that users of the stable ABI be directed to the Python equivalents, with the possibility of later adding inline functions for more commonly used API elements. PyObject_Print is the only one I would bother providing as part of the initial stable ABI implementation. Cheers, Nick. Search criteria: grep FILE \?\* * object.h:typedef int (*printfunc)(PyObject *, FILE *, int); object.h:PyAPI_FUNC(int) PyObject_Print(PyObject *, FILE *, int); - should provide inline equivalent fileobject.h:PyAPI_FUNC(char *) Py_UniversalNewlineFgets(char *, int, FILE*, PyObject *); marshal.h:PyAPI_FUNC(void) PyMarshal_WriteLongToFile(long, FILE *, int); marshal.h:PyAPI_FUNC(void) PyMarshal_WriteObjectToFile(PyObject *, FILE *, int); marshal.h:PyAPI_FUNC(long) PyMarshal_ReadLongFromFile(FILE *); marshal.h:PyAPI_FUNC(int) PyMarshal_ReadShortFromFile(FILE *); marshal.h:PyAPI_FUNC(PyObject *) PyMarshal_ReadObjectFromFile(FILE *); marshal.h:PyAPI_FUNC(PyObject *) PyMarshal_ReadLastObjectFromFile(FILE *); parsetok.h:PyAPI_FUNC(node *) PyParser_ParseFile (FILE *, const char *, grammar *, int, parsetok.h:PyAPI_FUNC(node *) PyParser_ParseFileFlags(FILE *, const char *, parsetok.h:PyAPI_FUNC(node *) PyParser_ParseFileFlagsEx(FILE *, const char *, pythonrun.h:PyAPI_FUNC(int) PyRun_AnyFileFlags(FILE *, const char *, PyCompilerFlags *); pythonrun.h:PyAPI_FUNC(int) PyRun_AnyFileExFlags(FILE *, const char *, int, PyCompilerFlags *); pythonrun.h:PyAPI_FUNC(int) PyRun_SimpleFileExFlags(FILE *, const char *, int, PyCompilerFlags *); pythonrun.h:PyAPI_FUNC(int) PyRun_InteractiveOneFlags(FILE *, const char *, PyCompilerFlags *); pythonrun.h:PyAPI_FUNC(int) PyRun_InteractiveLoopFlags(FILE *, const char *, PyCompilerFlags *); pythonrun.h:PyAPI_FUNC(struct _mod *) PyParser_ASTFromFile(FILE *, const char *, pythonrun.h:PyAPI_FUNC(struct _node *) PyParser_SimpleParseFileFlags(FILE *, const char *, pythonrun.h:PyAPI_FUNC(PyObject *) PyRun_FileExFlags(FILE *, const char *, int, pythonrun.h:PyAPI_FUNC(int) Py_FdIsInteractive(FILE *, const char *); pythonrun.h:PyAPI_FUNC(char *) PyOS_Readline(FILE *, FILE *, char *); pythonrun.h:PyAPI_DATA(char) *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE *, char *); - omit from stable ABI, recommend equivalent Python calls (may add inline versions to stable ABI over time if requested by developers) abstract.h: int PyObject_Print(PyObject *o, FILE *fp, int flags); - comment, not declaration (actual declaration is in object.h) grammar.h:void printgrammar(grammar *g, FILE *fp); grammar.h:void printnonterminals(grammar *g, FILE *fp); object.h:PyAPI_FUNC(void) _Py_PrintReferences(FILE *); object.h:PyAPI_FUNC(void) _Py_PrintReferenceAddresses(FILE *); Python.h:PyAPI_FUNC(FILE *) _Py_wfopen(const wchar_t *path, const wchar_t *mode); Python.h:PyAPI_FUNC(FILE*) _Py_fopen(PyObject *unicode, const char *mode); - private, omit from stable ABI -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Hi, Le jeudi 02 septembre 2010 11:13:22, vous avez écrit : 1. This function and PyUnicode_strcat are missing documentation. It's Py_UNICODE_strcat(), not PyUnicode_strcat(). But yes, Py_UNICODE_strcat() is not documented. But I didn't found any doc for other Py_UNICODE_str*() functions in Doc/c-api/*.rst. Does it mean that we should write a document for all these functions? They mimic the str*() C API. If PyUnicode_strdup() is kept public, it should be documented, yes. -- If you want to make this a public API function, it also needs to be renamed to fit the rest of the API. PyUnicode_strdup(): I don't like this name. In my first patch, it was called Py_UNICODE_strdup() but all Py_UNICODE_*() functions take Py_UNICODE* arguments, no PyUnicodeObject* argument. I'd suggest PyUnicode_AsUnicodeCopy() which then corresponds to PyUnicode_FromUnicode(), but I'm not sure whether we should have such a public API in the first place. PyUnicode_AsUnicodeCopy() is maybe a better name, I like it. -- What are they going to be used for? I am not able to merge my huge work on unicode import (see #8611, #9425 and the import_unicode svn branch) at once, so I'm splitting it into atomic commits. PyUnicode_strdup() and Py_UNICODE_strcat() are not used yet, but I plan to use them for the import machinery (Python/import.c) to replace char* by Py_UNICODE*. 2. Are you sure they need to be public APIs? About Py_UNICODE_strcat(): yes, why not? Other Py_UNICODE_str*() functions are pratical but also required to manipulate Py_UNICODE* strings. About PyUnicode_strdup() (PyUnicode_AsUnicodeCopy): I don't know. It is possible to rewrite it in few lines. Why don't you want to add them to the public API? For my work, it doesn't matter if it's public or not. This function uses PyMem_xxx API, I don't know if a third part library would like to rely on PyMem_xxx. -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Le jeudi 02 septembre 2010 23:19:04, Nick Coghlan a écrit : On Thu, Sep 2, 2010 at 6:51 PM, Georg Brandl g.bra...@gmx.net wrote: Hi Victor, 1. This function and PyUnicode_strcat are missing documentation. 2. Are you sure they need to be public APIs? What are they going to be used for? (I'm not sure myself, but I think we usually have a short notice here when new C APIs are added.) I believe I first saw them on Victor's branch for improved Unicode support (especially in the context of import). Yes, it is used in my branch. Py_UNICODE_strcat() is used in make_compiled_pathname(). Py_UNICODE_strdup() is used in make_source_pathname() and make_compiled_pathname(). I agree that private _Py prefixes are probably a better idea here. The public API should focus on Py_Unicode, with only a minimal collection of Py_UNICODE interfaces. Are you talking about Py_UNICODE_strcat() or Py_UNICODE_strdup() (called PyUnicode_strdup in py3k branch)? -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 status
On 02/09/10 09:04, Nick Coghlan wrote: I think it would be better if everything dealing with FILE* was a macro rather than a function, yes. How would that help? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two small PEP ideas
On Apr 30, 2010, at 12:51 PM, Martin v. Löwis wrote: Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers. I like Guido's idea. Just appoint have one of the experienced developers who is independent of the proposal and have them be the final arbiter. For example, Guido had earlier suggested that I decide the fate of the yield from proposal because I had experience in the topic but was not not personally involved in the proposal. Guido has set a good example for others to follow: * let a conversation evolve until an outcome is self-evident * or kill it early if it has no chance * or if discussion teases out all of the meaningful thinking but doesn't reach a clear conclusion, just make a choice based on instinct * have biases toward real-world use cases, towards ideas proven in other languages (category killers), towards slow rates of language evolution, and think about the long-term. It is better to have one experienced developer decide than to have a committee. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two small PEP ideas
On Thu, Sep 2, 2010 at 9:08 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Apr 30, 2010, at 12:51 PM, Martin v. Löwis wrote: Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers. I like Guido's idea. Just appoint have one of the experienced developers who is independent of the proposal and have them be the final arbiter. For example, Guido had earlier suggested that I decide the fate of the yield from proposal because I had experience in the topic but was not not personally involved in the proposal. Guido has set a good example for others to follow: * let a conversation evolve until an outcome is self-evident * or kill it early if it has no chance * or if discussion teases out all of the meaningful thinking but doesn't reach a clear conclusion, just make a choice based on instinct * have biases toward real-world use cases, towards ideas proven in other languages (category killers), towards slow rates of language evolution, and think about the long-term. It is better to have one experienced developer decide than to have a committee. +1. BTW, Barry just asked me about PEP 3149 and we decided to leave the ultimate decision to Georg and Benjamin. That's about as large a committee I'd be comfortable to appoint for any specific PEP. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two small PEP ideas
Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers. It is better to have one experienced developer decide than to have a committee. I feel that the concept of a BDFM (benevolent dictator for the moment) has the advantage of a clear visible responsibility, which most times leads to better decisions than if nobody is sure which ammunituion is the real one while shooting in a committee. Harald (tldr:+1) -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - Using PostgreSQL is mostly about sleeping well at night. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
