Please add a "versionadded" tag.
Am 03.09.2010 18:23, schrieb victor.stinner:
> Author: victor.stinner
> Date: Fri Sep 3 18:23:29 2010
> New Revision: 84456
> Document PyUnicode_AsUnicodeCopy()
> Modified: python/branches/py3k/Doc/c-api/unicode.rst
> --- python/branches/py3k/Doc/c-api/unicode.rst (original)
> +++ python/branches/py3k/Doc/c-api/unicode.rst Fri Sep 3 18:23:29 2010
> @@ -335,6 +335,14 @@
> buffer, *NULL* if *unicode* is not a Unicode object.
> +.. cfunction:: Py_UNICODE* PyUnicode_AsUnicodeCopy(PyObject *unicode)
> + Create a copy of a unicode string ending with a nul character. Return *NULL*
> + and raise a :exc:`MemoryError` exception on memory allocation failure,
> + otherwise return a new allocated buffer (use :cfunc:`PyMem_Free` to free the
> + buffer).
> .. cfunction:: Py_ssize_t PyUnicode_GetSize(PyObject *unicode)
> Return the length of the Unicode object.
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.
I have two somewhat unrelated thoughts about PEPs.
* Accepted: header
When PEP 3147 was accepted, I had a few folks ask that this be recorded in the
PEP by including a link to the BDFL pronouncement email. I realized that
there's no formal way to express this in a PEP, and many PEPs in fact don't
record more than the fact that it was accepted. I'd like to propose
officially adding an Accepted: header which should include a URL to the email
or other web resource where the PEP is accepted. I've come as close as
possible to this (without modifying the supporting scripts or PEP 1) in PEP
I'd be willing to update things if there are no objections.
* EOL schedule for older releases.
We have semi-formal policies for the lifetimes of Python releases, though I'm
not sure this policy is written down in any of the existing informational
PEPs. However, we have release schedule PEPs going back to Python 1.6. It
seems reasonable to me that we include end-of-life information in those PEPs.
For example, we could state that Python 2.4 is no longer even being maintained
for security, and we could state the projected date that Python 2.6 will go
into security-only maintenance mode.
I would not mandate that we go back and update all previous PEPs for either of
these ideas. We'd adopt them moving forward and allow anyone who's motivated
to backfill information opportunistically.
This is to let you all know that PEP 3149 is accepted.
Benjamin and I decided that on the basis that
* strong precedent is set with PEP 3147
* it is not mutually exclusive with PEP 384; should PEP 384 become
widely accepted, its use can fade out again
* it is a strictly optional feature
Barry promised the code will go in before this weekend's alpha2, so
that distributors can subject the new code to proper testing, should
they choose to use PEP 3149 features.
Is there any kind of internal file descriptor counter that can be
queried to debug issues with leaking resources?
It can be used in tests to check that all tests are finish with 0
It will be very useful while porting Python applications from Unix to
Windows. Unix is more tolerant to open files and can overwrite them
and do other nasty things. See the thread from comment #17 -
https://bugs.edge.launchpad.net/dulwich/+bug/557585/ - there is an
example of mmap that starts holding file descriptor somewhere long
before an error occurs. How could one debug this?
Right now I have to use FileMon. It includes information about
operated filenames, but no info about source code where this happens.
It will be nice to have some kind of counter with filename information
inside Python, so that it can be possible to get the full log of
events without manually messing with external system-specific tools
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
What do you think would be better?
I know the issue has been discussed several times already, however I couldn't find any reasonable explanation of its strange behaviour. The main problem with 'hasattr' function is that is swallows all exceptions derived from Exception class. It's a good thing that it doesn't do that with BaseException as it was fixed not a long time ago, but it's definitely not enough.
First of all, this behaviour of 'hasattr' contradicts with the very core principle of python: "Errors should never pass silently." And since 'hasattr' function is in builtins module and is a widely used function it impacts the whole language.
Secondly, take a look at the following:
>>> class Test:
... def attr(self):
>>> hasattr(Test(), 'attr')
There can be any exception instead of KeyError in the above snippet of code, but this small example shows how 'hasattr': misleadingly breaks the code logic (1) and masks bug (2). And that's the simplest possible example, there are much more in real life.
While (1) is maybe acceptable for someone, there is no excuse for the (2). Moreover, current 'hasattr' behaviour tremendously complicates use of '__getattribute__' magic. And forget about importlib magic with LazyImports, one 'hasattr' ruins everything by catching ImportError.
1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr'). Probably, Python 3.2 release is our last chance.
2) If you afraid that this new behaviour will break too much python 2 code converted with 2to3, we can introduce another 'hasattr' function defined in 2to3 module itself, and make it imported automatically in all files passed through 2to3 transformation pipeline. This new function will mimic 'hasattr' behaviour from python 2 and converted code should work as expected.