Le jeu. 4 juin 2020 à 00:14, Nathaniel Smith a écrit :
> On Wed, Jun 3, 2020 at 2:10 PM Victor Stinner wrote:
> > For the short term, my plan is to make structure opaque in the limited
> > C API, before breaking more stuff in the public C API :-)
>
> But you're also
Le mar. 9 juin 2020 à 23:59, Łukasz Langa a écrit :
> I mean, long story short, in Beta 2 you couldn’t do
> urllib.request.urlopen("https://www.python.org";).read() because it wouldn’t
> find root certificates due to a bug. Since this was a problem only apparent
> on an installed Python, it was
Hi,
I agree that embedding Python is an important use case and that we
should try to leak less memory and better isolate multiple
interpreters for this use case.
There are multiple projects to enhance code to make it work better
with multiple interpreters:
* convert C extension modules to multip
Hi INADA-san,
IMO Python 3.11 is too early because we don't emit a
DeprecationWarning on every single deprecation function.
1) Emit a DeprecationWarning at runtime (ex: Python 3.10)
2) Wait two Python releases: see
https://discuss.python.org/t/pep-387-backwards-compatibilty-policy/4421
3) Remove
Le mar. 16 juin 2020 à 10:42, Inada Naoki a écrit :
> Hmm, Is there any chance to add DeprecationWarning in Python 3.9?
In my experience, more and more projects are running their test suite
with -Werror, which is a good thing. Introducing a new warning is
likely to "break" many of these projects
Well done Brandt!
Even if only a few people had issues with zip(), I think that it was a
long awaited feature. It's great to have it in Python 3.10!
It wasn't trivial or convenient to emulate the feature (check manually
the length) on Python 3.9 and older.
zip(strict=True) should help to write m
re: [Python-Dev] When can we remove wchar_t* cache from string?
Le mar. 16 juin 2020 à 21:19, Steve Dower a écrit :
> On 16Jun2020 1641, Inada Naoki wrote:
> > * This change doesn't affect to pure Python packages.
> > * Most of the rest uses Cython. Since I already report an issue to Cython,
> >
Le mer. 17 juin 2020 à 12:38, Petr Viktorin a écrit :
> > Py_TYPE(), Py_REFCNT() and Py_SIZE() can no longer be used as l-value.
> > These changes also broke numpy. I helped to fix Cython and numpy (and
> > they are already fixed).
>
> Those are not all the projects that were broken by the change
620
Title: Hide implementation details from the C API
Author: Victor Stinner
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 19-June-2020
Python-Version: 3.10
Abstract
Introduce C API incompatible changes to hide implementation details.
Once most implementation
Hi INADA-san,
First of all, thanks for writing down a PEP!
Le jeu. 18 juin 2020 à 11:42, Inada Naoki a écrit :
> To support legacy Unicode object created by
> ``PyUnicode_FromUnicode(NULL, length)``, many Unicode APIs has
> ``PyUnicode_READY()`` check.
I don't see PyUnicode_READY() removal in t
Le mar. 23 juin 2020 à 03:47, Neil Schemenauer
a écrit :
> One final comment: I think even if we manage to cleanup the API and
> make it friendly for other Python implementations, there is going to
> be a fair amount of overhead. If you look at other "managed
> runtimes" that just seems unavoidab
Hi Neil,
Le mar. 23 juin 2020 à 03:47, Neil Schemenauer
a écrit :
> Thanks for putting work into this.
You're welcome, I took some ideas from your tagged pointer proof of
concept ;-) I recall that we met the same C API issues in our
experiments ;-)
> Changes must be made for
> well founded rea
Le mar. 23 juin 2020 à 04:02, Inada Naoki a écrit :
> Legacy unicode representation is using wstr so legacy unicode support
> is removed with wstr.
> PyUnicode_READY() will be no-op when wstr is removed. We can remove
> calling of PyUnicode_READY() since then.
>
> I think we can deprecate PyUnico
Le mar. 23 juin 2020 à 15:56, Petr Viktorin a écrit :
> > Adding or removing members of C structures is causing multiple backward
> > compatibility issues.
> >
> > Adding a new member breaks the stable ABI (PEP 384), especially for
> > types declared statically (e.g. ``static PyTypeObject MyType =
Le mar. 23 juin 2020 à 20:37, Neil Schemenauer
a écrit :
> My thinking is that, eventually, we would like to allow CPython to
> use something other than reference counting for internal PyObject
> memory management. In other systems with garbage collection, the
> memory allocator is typically tigh
Le mar. 23 juin 2020 à 16:56, Stefan Behnel a écrit :
> > Adding a new member breaks the stable ABI (PEP 384), especially for
> > types declared statically (e.g. ``static PyTypeObject MyType =
> > {...};``). In Python 3.4, the PEP 442 "Safe object finalization" added
> > the ``tp_finalize`` member
I commented https://github.com/python/peps/pull/1462 as a review.
Le mer. 24 juin 2020 à 10:21, Inada Naoki a écrit :
> Do you mean APIs relating to Py_UNICODE, but not relating to
> wstr nor legacy Unicode? (e.g. PyLong_FromUnicode, PyUnicode_Encode, etc...)
>
> We can remove them one-by-one bas
Le mer. 24 juin 2020 à 16:20, Stefan Behnel a écrit :
> Note, I understand the difference between ABI and API. Keeping
> PyTuple_GET_ITEM() a macro or inline function can break the ABI at some
> point once PyTupleObject changes in an incompatible way in Py3.14, and it
> may do different things in
Le mer. 24 juin 2020 à 21:16, Stefan Behnel a écrit :
> It couldn't because even today it is still fairly difficult to convert
> existing code to the limited API. Some code cannot even be migrated at all,
> e.g. because the entire buffer protocol is missing from it. Some bugs were
> only fixed in
In my experience, different people keep proposing the same idea until
it's recorded in the PEP. The PEP doesn't have to address all remarks
or take in account all ideas, but it's good to record the most common
proposed ideas. The important part is to show that other people's
opinions have been hear
,Hi Carl,
Le ven. 26 juin 2020 à 07:36, Carl Shapiro a écrit :
> It would be very helpful to broaden the objective of avoiding functions
> returning PyObject** to other types of pointers. I have in mind several
> functions in the C-API that return a char* pointer to the contents of an
> objec
bject** which is inefficient.
Right now, the C API is an exact mapping of CPython internals which
prevents us to enhance or optimize CPython, but also makes other
Python implementations inefficient when running C extensions.
Victor
Le ven. 26 juin 2020 à 23:37, Stefan Behnel a écrit :
>
Le dim. 28 juin 2020 à 04:39, Inada Naoki a écrit :
> ## Documented and have Py_DEPRECATED
>
> * PyLong_FromUnicode
> * PyUnicode_AsUnicodeCopy
> * PyUnicode_Encode
> * PyUnicode_EncodeUTF7
> * PyUnicode_EncodeUTF8
> * PyUnicode_EncodeUTF16
> * PyUnicode_EncodeUTF32
> * PyUnicode_EncodeUnicodeEsca
Le dim. 28 juin 2020 à 11:22, M.-A. Lemburg a écrit :
> as you may remember, I wasn't happy with the deprecations of the
> APIs in PEP 393, since there are no C API alternatives for
> the encoding APIs deprecated in the PEP, which allow direct
> encoding provided by these important codecs.
>
> AFA
Le lun. 29 juin 2020 à 08:41, Inada Naoki a écrit :
> That's all.
> Now I think it is safe to override deprecated APIs with private APIs
> accepts Unicode Object.
>
> * _PyUnicode_EncodeUTF7 -> PyUnicode_EncodeUTF7
Use PyUnicode_AsEncodedString("UTF-7"). This encoding is not common
enough to just
Le dim. 28 juin 2020 à 17:21, Inada Naoki a écrit :
> More aggressive idea: override current PyUnicode_EncodeXXX() apis.
> Change from `Py_UNICODE *object` to `PyObject *unicode`.
>
> This idea might look crazy. But PyUnicode_EncodeXXX APIs are
> deprecated for a long time, and there are only a f
Le lun. 29 juin 2020 à 12:36, Inada Naoki a écrit :
> * UTF16 and UTF32; `int byteorder` parameter.
* UTF-16 byte_order=0 means "UTF-16" encoding
* UTF-16 byte_order<0 means "UTF-16-BE" encoding
* UTF-16 byte_order>0 means "UTF-16-LE" encoding
Same applies for UTF-32.
> * UTF7; int base64SetO,
Le lun. 29 juin 2020 à 12:50, Inada Naoki a écrit :
> > > ## PyUnicode_EncodeDecimal
> > >
> > > It is not documented. It has not been deprecated by Py_DEPRECATED.
> > > Plan: Add Py_DEPRECATED in Python 3.9 and remove it in 3.11.
> >
> > I understood that the replacement function is the private
You missed the point of the PEP: "It becomes possible to experiment
with more advanced optimizations in CPython than just
micro-optimizations, like tagged pointers."
IMHO it's time to stop wasting our limited developer resources on
micro-optimizations and micro-benchmarks, but think about overall
Le mar. 30 juin 2020 à 13:53, M.-A. Lemburg a écrit :
> > I would prefer to analyze the list on a case by case basis. I don't
> > think that it's useful to expose every single encoding supported by
> > Python as a C function.
>
> (...)
> This does not mean we have to give up the symmetry in the C
If someone continues to feed the PEP 8 discussion, would it be
possible to change their account to require moderation for 1 day or
maybe even up to 1 week? I know that Mailman 3 makes it possible.
Victor
Le mar. 30 juin 2020 à 19:46, Tim Peters a écrit :
>
> [Brett Cannon wrote:]
> > Regardless
Le mer. 1 juil. 2020 à 03:53, Inada Naoki a écrit :
> I confirmed the performance regression, although the difference is 12%.
> And I find the commit cause the regression.
>
> https://github.com/python/cpython/commit/45ec5b99aefa54552947049086e87ec01bc2fc9a
> https://bugs.python.org/issue40170
>
>
There is the https://github.com/pyhandle/hpy project which is
implemented on top of the existing C API.
But this project doesn't solve problems listed in PEP 620, since
CPython must continue to support existing C extensions.
Victor
Le mer. 1 juil. 2020 à 23:43, Eric V. Smith a écrit :
>
> On 7/
om/vstinner/pythonci
Previously, PyEval_ReleaseLock() was used by
PyThreadState_DeleteCurrent(). I introduced a new
_PyEval_ReleaseLock() function which takes a tstate parameter, so
Python no longer uses PyEval_AcquireLock() and PyEval_ReleaseLock().
commit 23ef89db7ae46d160650263cc80479c2ed6693fb
Author:
Le jeu. 2 juil. 2020 à 14:44, Barry Scott a écrit :
> It's not obvious to me why the latin1 encoding is in this list as its just
> one of all the 8-bit char sets.
> Why is it needed?
The Latin-1 (ISO 8859-1) charset is kind of special: it maps bytes
0x00-0xFF to Unicode characters U+-U+00FF
UCS-2 means units of 16 bits so it's limited to Unicode BMP: U+-U+.
UCS-4 means units of 32 bits and so gives access to the whole
(current) Unicode character set.
Do you mean UTF-16 and UTF-32? UTF-16 supports the whole Unicode
character set but uses the annoying surrogate pairs for chara
Le ven. 3 juil. 2020 à 04:51, Inada Naoki a écrit :
> Actually, PyEval_ReleaseLock is used in three packages:
>
> pydevd-pycharm-202.5103.19/pydevd_attach_to_process/windows/attach.cpp
> 330:DEFINE_PROC(releaseLock, PyEval_Lock*, "PyEval_ReleaseLock",
> -160);
>
> jep-3.9.0/src/main/c/Jep
Le ven. 3 juil. 2020 à 11:19, Victor Stinner a écrit :
> Le ven. 3 juil. 2020 à 04:51, Inada Naoki a écrit :
> > Actually, PyEval_ReleaseLock is used in three packages:
> >
> > pydevd-pycharm-202.5103.19/pydevd_attach_to_process/windows/attach.cpp
> > 330:
stead.
Maybe we can still mark PyEval_ReleaseLock() as deprecated in Python
3.9, since it's just compiler warning, it's less intrusive than a
warning emitted at runtime.
Victor
Le ven. 3 juil. 2020 à 11:28, Inada Naoki a écrit :
>
> On Fri, Jul 3, 2020 at 6:23 PM Victor Stinner wro
Le sam. 13 juin 2020 à 12:39, Inada Naoki a écrit :
> Of course, there is an API to create an empty string: PyUnicode_New(0, 0);
> But since Cython is using `PyUnicode_FromString(NULL, 0)`,
> keep it working for some versions will mitigate the breaking change.
> Note that we can remove wchar_t cac
Sorry, ignore my comment: Cython no longer uses
PyUnicode_FromString(NULL, 0) in the master branch. The change was
backported to the 0.29.x branch, but this stable branch requires a
second fix, so I wrote it:
https://github.com/cython/cython/pull/3721
Victor
Le ven. 3 juil. 2020 à 16:00, Victor
Thanks for your advice! I confirm that raw GitHub code search is
painful with all copies of CPython code base :-(
I copied your notes in my
https://pythondev.readthedocs.io/test_next_python.html list :-)
victor
Le dim. 5 juil. 2020 à 07:55, Inada Naoki a écrit :
>
> Hi, folks.
>
> After 3.9 bec
Le mar. 7 juil. 2020 à 17:21, Inada Naoki a écrit :
> This PEP proposes to remove deprecated ``Py_UNICODE`` encoder APIs in
> Python 3.11:
Overall, I like the plan. IMHO 3.11 is a reasonable target version,
since on the top 4000 projects, only 2 are affected and it is easy to
fix them.
> Python
Hi,
As the PEP delegate of the PEP 623, I plan to accept PEP 623 "Remove
wstr from Unicode" next week. As far as I know, all previous remarks
have been taken in account.
https://www.python.org/dev/peps/pep-0623/
I worked with INADA-san to adjust his PEP 623 plan:
* DeprecationWarning warnings w
e and also to list affected C functions. It can
also be used and referenced in What's New in Python documents.
INADA-san: I let you update the PEP status. You may also announce the PEP
approval on the capi-sig mailing list.
Victor
Le mer. 8 juil. 2020 à 10:56, Victor Stinner a écrit :
>
Le mer. 12 août 2020 à 12:03, Ned Deily a écrit :
> Core developers: if you know of any additional security issues that should be
> addressed in these releases, please mark the relevant bpo issues as "release
> blocker" and, if possible, submit PRs for review prior to the end of
> 2020-08-13 AO
Le mer. 12 août 2020 à 14:09, Vinay Sharma a écrit :
> This is being tracked at https://bugs.python.org/issue39584.
> Could please comment whether this should be fixed by python, or we should
> wait for a macos fix.
This issue looks like a regular bug. I suggest not holding a security
release fo
Hi,
I checked the vulnerabilities that I'm tracking at
https://python-security.readthedocs.io/vulnerabilities.html
I noticed that https://bugs.python.org/issue39603 "http.client: HTTP
Header Injection in the HTTP method" lacks a fix in the 3.5 branch.
I backported the fix to 3.5: https://github.
Hi,
IMO a new PEP would avoid confusion:
* The new PEP should list differences with the previously rejected PEP
* The old PEP remains available unchanged to help to understand why it
has been rejected
It's common to have multiple PEP for the same feature. Once a PEP is
accepted, other PEP are re
not sure why this causes error.
> > >
> > > Pinning the dependency of setuptools to 49.6.0 in Doc/makefile runs the
> > > tests fine without error. Can you please try pinning it and see if it
> > > helps?
> > >
> > > I am not sure if the below commit i
Hi,
tl; dr Travis CI issues are now resolved thanks to Ernest!
During the last 3 months, the Travis CI job failed randomly to report
the build status to GitHub pull requests:
https://github.com/python/core-workflow/issues/371
I discovered that travis-ci.org uses the legacy GitHub API, whereas
th
Hi,
tl; dr Buildbots were unstable for 3 weeks but the issue is mostly resolved.
Since last January, the disk of the buildbot server was full every 2
weeks and The Night’s Watch had to fix it in the darkness for you
(usually, remove JUnit files and restart the server). The old machine
only has 8
Hi,
Aha, someone proposed the idea :-) I know that Debian removed
distutils from Python stdlib (it is a separate package) for a long
time.
You may mention https://github.com/pypa/distutils/ somewhere in the
PEP: "Python Module Distribution Utilities extracted from the Python
Standard Library". I
Hi Mark,
In 2016, I wrote PEP 511 "API for code transformers" which proposed a
different implementation but also used "preprocessor" use case in the
rationale:
"""
A preprocessor can be easily implemented with an AST transformer. A
preprocessor has various and different usages.
Some examples:
*
Hi,
The Python 3.8, 3.9 and 3.10 documentation can now be built with
Sphinx 3.2+, and Sphinx 2 is still supported. Sphinx 3.0 and 3.1 are
not supported.
On our continuous integration (CI), the Python 3.10 documentation is
now built with Sphinx 3 (version 3.2.1), whereas the Python 3.8 and
Python
Hi,
I need to help to attempt to optimize my experimental CPython fork
which uses tagged pointers.
When I proposed my PEP 620 "Hide implementation details from the C
API", I was asked about a proof that the PEP unlocks real optimization
possibilities. So I wrote an implementation of tagged pointe
Le lun. 21 sept. 2020 à 21:46, Antoine Pitrou a écrit :
> > The main benefit is the memory usage. For example, list(range(200))
> > uses 1656 bytes instead of 7262 (4x less memory).
>
> Hmm, how come? Aren't those tiny integers singletons already?
These numbers come from the code:
import sys
Le mer. 23 sept. 2020 à 10:48, Ivan Levkivskyi a écrit :
> // offtopic below, sorry
>
> In general, I think any significant perf wins will require some static info
> given to the Python compiler. I was thinking a long while ago about defining
> some kind of a standard protocol so that static typ
Le mer. 23 sept. 2020 à 13:49, Ivan Levkivskyi a écrit :
> Sure, but JIT optimizations assume there are some "hot spots" in the code
> where e.g. a function is called in a loop, so that type information can be
> gathered and re-used.
> The problem is that in my experience there are many applicat
FYI Python 3.9 has a new sys.platlibdir to choose between "lib" and
"lib64". Fedora and OpenSUSE use /usr/lib64 directory on 64-bit
systems rather than /usr/lib.
On 64-bit Fedora, sys.platlibdir is set to lib64:
$ python3.9 -c 'import sys; print(sys.platlibdir)'
lib64
Commented (simplified) sys.
Hi,
Would you mind reporting the issue to
https://github.com/python/core-workflow/issues so we can aggregate
information about this issue?
Latest changes related to Travis CI.
Travis CI migrated from legacy API to new GitHub Action API:
https://github.com/python/core-workflow/issues/371
Removal
Stefan created https://github.com/python/core-workflow/issues/376
Victor
Le lun. 5 oct. 2020 à 12:25, Victor Stinner a écrit :
>
> Hi,
>
> Would you mind reporting the issue to
> https://github.com/python/core-workflow/issues so we can aggregate
> information about this
Hi Walter,
> https://github.com/python/cpython/commit/a8bf44d04915f7366d9f8dfbf84822ac37a4bab3
Le mar. 6 oct. 2020 à 17:02, Walter Dörwald a écrit :
> It would be even simpler to use unicodedata.lookup() which returns the
> unicode character when passed the name of the character
That was my fi
Le ven. 9 oct. 2020 à 04:14, Ivan Pozdeev via Python-Dev
a écrit :
> I don't see the point of requiring to "write an apology", especially *before
> a 12-month ban*. If they understand that their behavior is wrong, there's no
> need for a ban, at least not such a long one; if they don't, they cle
Hi,
Le ven. 9 oct. 2020 à 21:02, Brett Cannon a écrit :
> Another way to look at this is to realize that Stefan's behaviour may have
> scared off people who would have been willing to contribute to the decimal
> module. As Christian pointed out, there is already one instance of a
> contributor
Hi,
As a member of the Night's Watch, I'm fixing the CI in the darkness
for you (*). Last weeks, I managed to fix most issues. But I decided
to give up on test_asyncio failures. I no longer have the bandwidth to
investigate these complex issues.
(*) https://pythondev.readthedocs.io/ci.html
I ne
I suggest to limit to one "dot" per week, since CodeSpeed (the website
to browse the benchmark results) is somehow limited to 50 dots (it can
display more if you only display a single benchmark).
Previously, it was closer to one "dot" per month which allowed to
display a timeline over 5 years. In
Hi,
I was always confused by the __version__ variable of *some* modules.
It's surprising since it's no longer incremented when the module is
fixed or gets new features. Also, the number is unrelated to the
Python version. I suggest to remove __version__.
__author__, __credits__, __email__, __copy
If the __version__ variable is used, I suggest to start with a
deprecation period using a module __getattr__(): emit
DeprecationWarning, and only remove these variables in 2 Python
releases (PEP 387).
sys.version or sys.version_info can be used instead of argparse.__version__, no?
Victor
Le mer.
Le mer. 14 oct. 2020 à 17:59, Antoine Pitrou a écrit :
> unpack-sequence is a micro-benchmark. (...)
I suggest removing it.
I removed other similar micro-benchmarks from pyperformance in the
past, since they can easily be misunderstood and misleading. For
curious people, I'm keeping a collection
Hi Daniel,
> Good:
> Many requested assignments:
> Thanks everyone that asked for bugs. If anyone else wants more,
> just let me know :)
I like everything related to Unicode and the separation of byte and character
strings in Python3 :-)
I already have some pending issues..
Le Thursday 12 February 2009 14:10:32, vous avez écrit :
> Victor Stinner wrote:
> > I like everything related to Unicode and the separation of byte and
> > character strings in Python3 :-)
>
> That's a big one. But Ezio Melotti already asked for Unicode, so I
> hav
uot;, line 341, in _cmp
return cmp(self.version, other.version)
NameError: global name 'cmp' is not defined
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
me and max memory limits (or signal.alarm() for the timeout)
- Run a fuzzer on Python and fix all bugs :-)
I wrote a short document in Python's wiki on the different security projects:
http://wiki.python.org/moin/Security
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
__
load(__builtins__)
>>> file('0wn3d', 'w').write('w00t\n')
>>>
$ cat 0wn3d
w00t
> Dinner and drinks on me for an evening -- when you are next in London
> or I am in your town -- to the first person who manages to break
> safelite.py
Le Monday 23 February 2009 22:36:47, vous avez écrit :
> >>>> reload(__builtins__)
> (...)
>
> Tav should have made another stipulation: the attack must not be
> trivial to fix.
Why not? Any hole is enough to break a jail. The cracker doesn't care if it's
Le Tuesday 24 February 2009 00:51:25 Farshid Lashkari, vous avez écrit :
> It seems like some code in safelite passes a file object to
> isinstance. By overriding the builtin isinstance function I can get
> access to the original file object and create a new one.
Wow, excellent idea!
-
f=open('x', mode) -> opened in write mode
... hey! The rules (safelite.py) changed one more time! The check on mode is
now:
if type(mode) is not type(''):
raise TypeError("mode has to be a string.")
Could you keep all
7;
mode = Mode('w')
f = FileReader('0wn3d', 'w')
fileobj = get_cell_value(f.tell.__getattribute__('func_closure')[0])
fileobj.write('twice!\n')
f.close()
-
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
Le Tuesday 24 February 2009 01:31:55 Victor Stinner, vous avez écrit :
> (...)
> But how can we get the closure if b.func_closure doesn't exist? Oh, wait!
> What's this: b.__getattribute__...
> -
> secret = get_cell_value(b.__getattr
victor> f.tell.__getattribute__('func_closure')
tak> But, have you actually run that code?
Ooops, I modified my local copy of safelite.py to disable func_xxx
protections :-p With the latest version of safelite.py, my exploit doesn't
work anymore. Sorry.
--
Victor S
ell, add proxies to anything going to the jail ;-) and make sure that
a proxy can not be modified by itself or read private attributes
My approach is maybe naive and imposible to implement :-)
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
_
the original environment. Example:
...
jail(evil_func) # called in the jail
# unsafe environment with __subclasses__, f_code, etc.
...
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
Python-Dev@python.or
le-character string byte into memory at the current position
of the file pointer; the file position is advanced by 1. If the mmap was
created with ACCESS_READ, then writing to it will throw a TypeError
exception.
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
erent regex on to catch "...c..." with Py_BuildValue and
PyArg_Parse... because a function may have other arguments or specify the
function name with "...:name":
http://bugs.python.org/issue5391
It looks like msvcrt.putch(char) and msvcrt.ungetch(char) use th
Pthon 3.1alpha1 because 2.6.1 only
includes pybench 2.0
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
Computer:
* Ubuntu 7.10
* Pentium(R) 4 CPU 3.00GHz (32 bits)
* 2 GB
Le Sunday 08 March 2009 13:20:34 Antoine Pitrou, vous avez écrit :
> Hi,
>
> Victor Stinner haypocalc.com> writes:
> > Summary (minimum total) on 32 bits CPU:
> > * Python 2.6.1: 8762 ms
> > * Python 3.0.1: 8977 ms
> > * Python 3.1a1: 9228 ms (slower tha
e and character
getarg('C') => int accepts byte and character
So we have:
- getarg('c') -> one byte (integer in [0; 255])
- getarg('C') -> one character (code in [0; INTMAX])
Note: Why not using Py_UNICODE instead of int?
Usage of "C" format:
Le Tuesday 17 March 2009 13:52:16 Victor Stinner, vous avez écrit :
> I realised with the issue #3446 that getarg('c') (get a byte) accepts not
> only a byte string of 1 byte, but also an unicode string of 1 character (if
> the character code is in [0; 255]). I don't think
msvcrt.ungetwch(unicode string of 1 character)
msvcrt.putwch(unicode string of 1 character)
So "c" looks to be the right format for putch() and ungetch().
See also http://bugs.python.org/issue5410
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
_
n integers ;-)
There are other importants features to optimize like:
- unicode string ("str" in python3)
- I/O: io-c in py3k branch is already much better, but I'm sure that
we can do better ;-)
- etc.
--
Victor Stinner aka haypo
http
There are different patches to improve regex library. You can start with:
http://bugs.python.org/issue2636
I don't know that status of the issues, but it can be an interresting project.
--
Victor Stinner aka haypo
http://www.haypocalc.com
n/Security
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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
ail at uninstallation"
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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
enable
the new behaviour. But is it really needed to keep the backward compatibility?
I wrote a proof of concept attached to the issue #7651. My patch only changes
the behaviour of TextIOWrapper for reading files starting with a BOM. It
doesn't work yet if a seek() is used before the first read.
suppose that "BOM" would be a
magical value specific to read a text file (open(filename, "r")), not a real
codec?
Otherwise which encoding should be used for open(filename, "w",
encoding="BOM")?
--
Victor Stinner
http://www.haypocalc.com/
doesn't work for writing into a file, so open(filename, "w",
encoding="BOM") raises a ValueError.
--
Victor Stinner
http://www.haypocalc.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
dify open()+TextIOWrapper instead of writing a new function
because I would like to avoid an extra read operation (syscall) on the file.
With my implementation, no specific read operation is needed to detect the
BOM. The BOM is simply checked in the first _read_chunk().
--
Victor Stinner
http://www.hayp
ou call it encoding="sniff".
Good idea, I choosed open(filename, encoding="BOM").
--
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
o, some non-file streams are not seekable, and so
> > can't be guessed via a pre-pass.
>
> But what if the file were in (for example) a zip file? I think you
> definitely want to have access to this functionality outside of open().
FYI my patch (encoding="BOM") i
2201 - 2300 of 3215 matches
Mail list logo
