Re: [Python-Dev] PEP 393 merged
On Wed, Sep 28, 2011 at 8:41 AM, Guido van Rossum wrote: > Congrats! Python 3.3 will be better because of this. > > On Wed, Sep 28, 2011 at 12:48 AM, "Martin v. Löwis" > wrote: > > I have now merged the PEP 393 implementation into default. > > The main missing piece is the documentation; contributions are > > welcome. > +10 This is great! Thank you Martin! -Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python Core Tools
Hello, I've stumbled upon Dave Beazley's article [1] about trying ancient GIL removal patch at http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-removal-patch-of.html and looking at the output of Python dis module thought that it would be cool if there were tools to inspect, explain and play with Python bytecode. Little visual assembler, that shows bytecode and disassembly side by side and annotates the listing with useful hints (like interpreter code optimization decisions). That will greatly help many new people understand how Python works and explain complicated stuff like GIL and stackless by copy/pasting pictures from there. PyPy has a tool named 'jitviewer' [2] that may be that I am looking for, but the demo is offline. But even without this tool I know that speakers at conferences create various useful scripts to gather interesting stats and visualize Python internals. I can name at least 'dev in a box' [3] project to get people started quickly with development, but I am sure there many others exist. Can you remember any tools that can be useful in Python core development? Maybe you use one every day? I'd like to compile a list of such tools and put in to Wiki to allow people have some fun with Python development without the knowledge of C. 1. http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-removal-patch-of.html 2. http://morepypy.blogspot.com/2011/08/visualization-of-jitted-code.html 3. http://hg.python.org/devinabox/ -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Core Tools
On Sun, Oct 2, 2011 at 5:02 AM, anatoly techtonik wrote: > Hello, > > I've stumbled upon Dave Beazley's article [1] about trying ancient GIL > removal patch at > http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-removal-patch-of.html > and looking at the output of Python dis module thought that it would > be cool if there were tools to inspect, explain and play with Python > bytecode. Little visual assembler, that shows bytecode and disassembly > side by side and annotates the listing with useful hints (like > interpreter code optimization decisions). That will greatly help many > new people understand how Python works and explain complicated stuff > like GIL and stackless by copy/pasting pictures from there. PyPy has a > tool named 'jitviewer' [2] that may be that I am looking for, but the > demo is offline. I put demo back online. https://bitbucket.org/pypy/pypy/src/59460302c713/lib_pypy/disassembler.py this might be of interest. It's like dis module except it creates objects instead of printing them > > But even without this tool I know that speakers at conferences create > various useful scripts to gather interesting stats and visualize > Python internals. I can name at least 'dev in a box' [3] project to > get people started quickly with development, but I am sure there many > others exist. Can you remember any tools that can be useful in Python > core development? Maybe you use one every day? I'd like to compile a > list of such tools and put in to Wiki to allow people have some fun > with Python development without the knowledge of C. > > > 1. http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-removal-patch-of.html > 2. http://morepypy.blogspot.com/2011/08/visualization-of-jitted-code.html > 3. http://hg.python.org/devinabox/ > -- > anatoly t. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com > ___ Python-Dev mailing list [email protected] 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-393: request for keeping PyUnicode_EncodeDecimal()
"Martin v. Löwis" wrote:
> > longobject.c still used PyUnicode_EncodeDecimal() until 10 months
> > ago (8304bd765bcf). I missed the PyUnicode_TransformDecimalToASCII()
> > commit, probably because #10557 is still open.
> >
> > That's why I wouldn't like to implement the function myself at least
> > until the API is settled.
>
> I don't understand. If you implement it yourself, you don't have to
> worry at all what the API is.
What I'm looking for is a public function that is silently updated if
python-dev decides to accept other numerical input. As I understand
from your comments below, PyUnicode_EncodeDecimal() is frozen, so
that function does indeed not help.
I would consider it reasonable for PyUnicode_TransformDecimalAndSpaceToASCII()
to be documented as:
"This function might accept different numerical input in the future."
The reason is that some people would like to accept additional input
(see #6632), while others would like to restrict input. If there is
a function that will always track whatever will be decided, extension
authors don't have to worry about being up-to-date.
>out = malloc(PyUnicode_GET_LENGTH(in)+1);
>for (i = 0; i < PyUnicode_GET_LENGTH(in); i++) {
>Py_UCS4 ch = PyUnicode_READ_CHAR(in, i);
>int d = Py_UNICODE_TODIGIT(ch);
>if (d != -1) {
> out[i] == '0'+d;
> continue;
>}
>if (ch < 128)
> out[i] = ch;
>else {
> error();
> return;
>}
>}
>out[i] = '\0';
Thanks for that. I think alternative leading and trailing whitespace would
need to be handled as well: Decimal("\u180E1.233").
> > Will PyUnicode_TransformDecimalAndSpaceToASCII() be public?
>
> It's already included in 3.2, so it can't be removed that easily.
> I wish it had been private, though - we have way too many API functions
> dealing with Unicode.
I can find PyUnicode_TransformDecimalToASCII() in 3.2, but not
PyUnicode_TransformDecimalAndSpaceToASCII().
Stefan Krah
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Core Tools
On Sun, Oct 2, 2011 at 8:05 AM, Maciej Fijalkowski wrote: > On Sun, Oct 2, 2011 at 5:02 AM, anatoly techtonik wrote: >> Hello, >> >> I've stumbled upon Dave Beazley's article [1] about trying ancient GIL >> removal patch at >> http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-removal-patch-of.html >> and looking at the output of Python dis module thought that it would >> be cool if there were tools to inspect, explain and play with Python >> bytecode. Little visual assembler, that shows bytecode and disassembly >> side by side and annotates the listing with useful hints (like >> interpreter code optimization decisions). That will greatly help many >> new people understand how Python works and explain complicated stuff >> like GIL and stackless by copy/pasting pictures from there. PyPy has a >> tool named 'jitviewer' [2] that may be that I am looking for, but the >> demo is offline. > > I put demo back online. > It's just that SimpleHTTPServer doesn't quite survive slashdot effect. Where do I fill a bug report :) Cheers, fijal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Add a new builtin strarray type to Python?
Le samedi 1 octobre 2011 22:21:01, Antoine Pitrou a écrit :
> So, since people are confused at the number of possible options, you
> propose to add a new option and therefore increase the confusion?
The idea is to provide an API very close to the str type. So if your program
becomes slow in some functions and these functions are manipulating strings:
just try to replace str() by strarray() at the beginning of your loop, and
redo your benchmark.
I don't know if we really need all str methods: ljust(), endswith(),
isspace(), lower(), strip(), ... or if a UnicodeBuilder supporting in-place
a+=b would be enough. I suppose that it just would be more practical to have
the same methods.
Another useful use case is to be able to replace a substring: using strarray,
you can use the standard array[a:b] = newsubstring to insert, replace or
delete. Extract of strarray unit tests:
abc = strarray('abc')
abc[:1] = '123' # replace
self.assertEqual(abc, '123bc')
abc[3:3] = '45' # insert
self.assertEqual(abc, '12345bc')
abc[5:] = '' # delete
self.assertEqual(abc, '12345')
But only "replace" would be O(1). ("insert" requires less work than a replace
in a classic str if the replaced string is near the end.) You cannot
insert/delete using StringIO, str.join, or StringBuilder/UnicodeBuilder, but
you can using array('u'). Of course, you can replace a single character:
strarray[i] = 'x'.
(Using array[a:b]=newstr and array.index(), you can implement your in-place
.replace() function.)
> I don't understand why StringIO couldn't simply be optimized a little
> more, if it needs to.
Honestly, I didn't know that StringIO.write() is more efficient than str+=str,
and it is surprising to use the io module (which is supposed to be related to
files) to manipulate strings. But we can maybe document some "trick" (is it a
trick or not?) in str documementation (and in FAQ, and in stackoverflow.com,
and ...).
> Or, if straightforward string concatenation really needs to be fast,
> then str + str should be optimized (like it used to be).
We cannot have best performance and lowest memory usage at the same time with
the new str implementation (PEP 393). The new implementation is even more
focused on read-only (constant) strings than the previous one (Py_UNICODE
array using two memory blocks).
The PEP 393 uses one memory block, you cannot resize a str object anymore. The
old str type, StringIO, array (and strarray) use two memory blocks, so it is
possible to resize them (objects keep their identifier after the resize).
I *might* be possible to implement strarray that is fast on concatenation and
has small memory footprint, but we cannot use it for the str type because str
is immutable in Python.
--
On a second thaught, it may be easy to implement strarray if it reuses
unicodeobject.c. For example, strarray can be a special case (mutable) of
PyUnicodeObject (which use two memory blocks): the string would always be
ready, be never compact.
By the way, bytesobject.c and bytearrayobject.c is a fiasco: most functions are
duplicated whereas the code is very close. A big refactor is required to
remove duplicate code there.
Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Add a new builtin strarray type to Python?
On Sun, 2 Oct 2011 15:00:01 +0200 Victor Stinner wrote: > > > I don't understand why StringIO couldn't simply be optimized a little > > more, if it needs to. > > Honestly, I didn't know that StringIO.write() is more efficient than > str+=str, > and it is surprising to use the io module (which is supposed to be related to > files) to manipulate strings. StringIO is an in-memory file-like object, like in 2.x (where it lived in the "cStringIO" module). I don't think it's a novel thing. > The PEP 393 uses one memory block, you cannot resize a str object anymore. I don't know why you're saying that. The concatenation optimization worked in 2.x where the "str" type also used only one memory block. You just have to check that the refcount is about to drop to zero. Of course, resizing only works if the two unicode objects are of the same "kind". Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown
On 10/02/11 01:14, victor.stinner wrote: > http://hg.python.org/cpython/rev/9124a00df142 > changeset: 72573:9124a00df142 > parent: 72571:fa0b1e50270f > user:Victor Stinner > date:Sat Oct 01 23:48:37 2011 +0200 > summary: > PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown > > files: > Objects/unicodeobject.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c > --- a/Objects/unicodeobject.c > +++ b/Objects/unicodeobject.c > @@ -1211,7 +1211,7 @@ > case PyUnicode_4BYTE_KIND: > return _PyUnicode_FromUCS4(buffer, size); > } > -assert(0); > +PyErr_SetString(PyExc_ValueError, "invalid kind"); > return NULL; > } Is that really a ValueError? It should only be a ValueError if the user could trigger that error. Otherwise it should be a SystemError. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Add a new builtin strarray type to Python?
Antoine Pitrou writes: > StringIO is an in-memory file-like object, like in 2.x (where it lived > in the "cStringIO" module). I don't think it's a novel thing. The problem is the name "StringIO". Something like "StringStream" or "StringBuffer" might be more discoverable. I personally didn't have trouble deducing that "StringIO" means "treat a string like a file", but it's not immediately obvious what the module is for (unless you already know). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Add a new builtin strarray type to Python?
Le dimanche 02 octobre 2011 à 23:39 +0900, Stephen J. Turnbull a écrit : > Antoine Pitrou writes: > > > StringIO is an in-memory file-like object, like in 2.x (where it lived > > in the "cStringIO" module). I don't think it's a novel thing. > > The problem is the name "StringIO". Something like "StringStream" or > "StringBuffer" might be more discoverable. I personally didn't have > trouble deducing that "StringIO" means "treat a string like a file", > but it's not immediately obvious what the module is for (unless you > already know). I'm not sure why "StringStream" or "StringBuffer" would be more discoverable, unless you're coming from a language where these names are well-known. A "stream" is usually related to I/O, anyway; while a "buffer" is more like an implementation detail. I personally like the relative tersity of "StringIO". ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown
On 10/02/11 16:21, Georg Brandl wrote: > On 10/02/11 01:14, victor.stinner wrote: >> http://hg.python.org/cpython/rev/9124a00df142 >> changeset: 72573:9124a00df142 >> parent: 72571:fa0b1e50270f >> user:Victor Stinner >> date:Sat Oct 01 23:48:37 2011 +0200 >> summary: >> PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown >> >> files: >> Objects/unicodeobject.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> >> diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c >> --- a/Objects/unicodeobject.c >> +++ b/Objects/unicodeobject.c >> @@ -1211,7 +1211,7 @@ >> case PyUnicode_4BYTE_KIND: >> return _PyUnicode_FromUCS4(buffer, size); >> } >> -assert(0); >> +PyErr_SetString(PyExc_ValueError, "invalid kind"); >> return NULL; >> } > > Is that really a ValueError? It should only be a ValueError if the user > could trigger that error. Otherwise it should be a SystemError. (And by "user", I mean "Python programmer".) Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown
2011/10/2 Georg Brandl : > On 10/02/11 01:14, victor.stinner wrote: >> http://hg.python.org/cpython/rev/9124a00df142 >> changeset: 72573:9124a00df142 >> parent: 72571:fa0b1e50270f >> user: Victor Stinner >> date: Sat Oct 01 23:48:37 2011 +0200 >> summary: >> PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown Also, could I remind you that a better commit message is probably "make PyUnicode_FromKindAndData raise a ValueError if the kind is unknown". Moreover, I wonder is the kind should be an enumeration, then people would get a warning at least. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Add a new builtin strarray type to Python?
On Sun, 02 Oct 2011 16:41:16 +0200 Antoine Pitrou wrote: > Le dimanche 02 octobre 2011 à 23:39 +0900, Stephen J. Turnbull a écrit : > > Antoine Pitrou writes: > > > > > StringIO is an in-memory file-like object, like in 2.x (where it lived > > > in the "cStringIO" module). I don't think it's a novel thing. > > > > The problem is the name "StringIO". Something like "StringStream" or > > "StringBuffer" might be more discoverable. I personally didn't have > > trouble deducing that "StringIO" means "treat a string like a file", > > but it's not immediately obvious what the module is for (unless you > > already know). > > I'm not sure why "StringStream" or "StringBuffer" would be more > discoverable, unless you're coming from a language where these names are > well-known. A "stream" is usually related to I/O, anyway; while a > "buffer" is more like an implementation detail. > I personally like the relative tersity of "StringIO". Apparently the real word is "terseness". My bad. Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Add a new builtin strarray type to Python?
There are a number of issues that are being conflated by this thread. 1) Should str += str be fast. In my opinion, the answer is an obvious and resounding no. Strings are immutable, thus repeated string addition is O(n**2). This is a natural and obvious conclusion. Attempts to change this are only truly possible on CPython, and thus create a worse enviroment for other Pythons, as well as a quite misleading, as they'll be extremely brittle. It's worth noting that, to my knowledge, JVMs haven't attempted hacks like this. 2) Should we have a mutable string. Personally I think this question just misses the point. No one actually wants a mutable string, the closest thing anyone asks for is faster string building, which can be solved by a far more specialized thing (see (3)) without all the API hangups of "What methods mutate?", "Should it have every str method", or "Is it a dropin replacement?". 3) And, finally the question that prompted this enter thing. Can we have a better way of incremental string building than the current list + str.join method. Personally I think unless your interest is purely in getting the most possible speed out of Python, the current idiom is probably acceptable. That said, if you want to get the most possible speed, a StringBuilder in the vein PyPy offers is the only sane way. It's able to be faster because it has very little ways to interact with it, and once you're done it reuses it's buffer to create the Python level string object, which is to say there's no need to copy it at the end. As I said, unless your interest is maximum performance, there's nothing wrong with the current idiom, and we'd do well to educate our users, rather than have more hacks. Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Add a new builtin strarray type to Python?
Antoine Pitrou writes: > I'm not sure why "StringStream" or "StringBuffer" would be more > discoverable, unless you're coming from a language where these names are > well-known. I think they are, but it doesn't really matter, since both are a bit lame, and I doubt either is sufficiently suggestive to be worth changing the name of the module, or even providing an alias. I wish I had a better name to offer, that's all. > I personally like the relative tersity of "StringIO". The issue is not that I *dislike* the name; I *personally* like the name fine. It's that it's definitely not doing anything to reduce the frequency of the "efficient string concatenation" FAQ. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg tips (was Re: [Python-checkins] cpython (merge default -> default): Merge heads.)
Great tips. Can we add them to the developer guide somewhere? Thank you, Vlad On Thu, Sep 29, 2011 at 12:54 AM, Ezio Melotti wrote: > Tip 1 -- merging heads: > > A while ago Éric suggested a nice tip to make merges easier and since I > haven't seen many people using it and now I got a chance to use it again, I > think it might be worth showing it once more: > > # so assume you just committed some changes: > $ hg ci Doc/whatsnew/3.3.rst -m 'Update and reorganize the whatsnew entry > for PEP 393.' > # you push them, but someone else pushed something in the meanwhile, so the > push fails > $ hg push > pushing to ssh://[email protected]/cpython > searching for changes > abort: push creates new remote heads on branch 'default'! > (you should pull and merge or use push -f to force) > # so you pull the other changes > $ hg pull -u > pulling from ssh://[email protected]/cpython > searching for changes > adding changesets > adding manifests > adding file changes > added 4 changesets with 5 changes to 5 files (+1 heads) > not updating, since new heads added > (run 'hg heads' to see heads, 'hg merge' to merge) > # and use "hg heads ." to see the two heads (yours and the one you pulled) > in the current branch > $ hg heads . > changeset: 72521:e6a2b54c1d16 > tag: tip > user:Victor Stinner > date:Thu Sep 29 04:02:13 2011 +0200 > summary: Fix hex_digit_to_int() prototype: expect Py_UCS4, not > Py_UNICODE > > changeset: 72517:ba6ee5cc9ed6 > user:Ezio Melotti > date:Thu Sep 29 08:34:36 2011 +0300 > summary: Update and reorganize the whatsnew entry for PEP 393. > # here comes the tip: before merging you switch to the other head (i.e. the > one pushed by Victor), > # if you don't switch, you'll be merging Victor changeset and in case of > conflicts you will have to review > # and modify his code (e.g. put a Misc/NEWS entry in the right section or > something more complicated) > $ hg up e6a2b54c1d16 > 6 files updated, 0 files merged, 0 files removed, 0 files unresolved > # after the switch you will merge the changeset you just committed, so in > case of conflicts > # reviewing and merging is much easier because you know the changes already > $ hg merge > 1 files updated, 0 files merged, 0 files removed, 0 files unresolved > (branch merge, don't forget to commit) > # here everything went fine and there were no conflicts, and in the diff I > can see my last changeset > $ hg di > diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst > [...] > # everything looks fine, so I can commit the merge and push > $ hg ci -m 'Merge heads.' > $ hg push > pushing to ssh://[email protected]/cpython > searching for changes > remote: adding > changesets > > remote: adding manifests > remote: adding file changes > remote: added 2 changesets with 1 changes to 1 files > remote: buildbot: 2 changes sent successfully > remote: notified [email protected] of incoming changeset > ba6ee5cc9ed6 > remote: notified [email protected] of incoming changeset > e7672fe3cd35 > > This tip is not only useful while merging, but it's also useful for > python-checkins reviews, because the "merge" mail has the same diff of the > previous mail rather than having 15 unrelated changesets from the last week > because the committer didn't pull in a while. > > > Tip 2 -- extended diffs: > > If you haven't already, enable git diffs, adding to your ~/.hgrc the > following two lines: > >> [diff] >> git = True >> > (this is already in the devguide, even if 'git = on' is used there. The > mercurial website uses git = True too.) > More info: > http://hgtip.com/tips/beginner/2009-10-22-always-use-git-diffs/ > > > Tip 3 -- extensions: > > I personally like the 'color' extension, it makes the output of commands > like 'hg diff' and 'hg stat' more readable (e.g. it shows removed lines in > red and added ones in green). > If you want to give it a try, add to your ~/.hgrc the following two lines: > >> [extensions] >> color = >> > > If you find operations like pulling, updating or cloning too slow, you > might also want to look at the 'progress' extension, which displays a > progress bar during these operations: > >> [extensions] >> progress = >> > > > Tip 4 -- porting from 2.7 to 3.2: > > The devguide suggests: >> >> hg export a7df1a869e4a | hg import --no-commit - >> > but it's not always necessary to copy the changeset number manually. > If you are porting your last commit you can just use 'hg export 2.7' (or > any other branch name): > * using the one-dir-per-branch setup: > wolf@hp:~/dev/py/2.7$ hg ci -m 'Fix some bug.' > wolf@hp:~/dev/py/2.7$ cd ../3.2 > wolf@hp:~/dev/py/3.2$ hg pull -u ../2.7 > wolf@hp:~/dev/py/3.2$ hg export 2.7 | hg import --no-commit - > * using the single-dir setup: > wolf@hp:~/dev/python$ hg branch > 2.7 > wolf@hp:~/dev/python$ hg ci -m 'Fix some bug.' > wolf@hp:~/dev/python$ hg up 3.2 # here you might enjoy the progress > extension > wolf@hp:~/dev/python$ h
Re: [Python-Dev] What it takes to change a single keyword.
Thanks to you both, I have made some progress on introducing my own keywords to python interpreter. I think it is very kind of you to answer my question. I think I can take it from here. Thanks again :) 02 Ekim 2011 05:42 tarihinde Nick Coghlan yazdı: > 2011/10/1 "Martin v. Löwis" : > >> First of all, I am sincerely sorry if this is wrong mailing list to ask > >> this question. I checked out definitions of couple other mailing list, > >> and this one seemed most suitable. Here is my question: > > > > In principle, python-list would be more appropriate, but this really > > is a border case. So welcome! > > > >> Let's say I want to change a single keyword, let's say import keyword, > >> to be spelled as something else, like it's translation to my language. I > >> guess it would be more complicated than modifiying Grammar/Grammar, but > >> I can't be sure which files should get edited. > > > > Hmm. I also think editing Grammar/Grammar should be sufficient. Try > > restricting yourself to ASCII keywords first; this just worked fine for > > me. > > For any changes where that isn't sufficient, then > http://docs.python.org/devguide/grammar.html provides a helpful list > of additional places to check (and > http://docs.python.org/devguide/compiler.html provides info on how it > all hangs together). > > However, rather than *changing* the keywords, it would likely be > better to allow *alternate* keywords to avoid the problem Martin > mentioned with existing Python code failing to run (including the > entire standard library). > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > -- http://yasar.serveblog.net/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Add a new builtin strarray type to Python?
On Sat, Oct 1, 2011 at 7:17 PM, Victor Stinner wrote: > I'm writing this email to ask you if this type solves a real issue, or if we > can just prove the super-fast str.join(list of str). I'm -1 on hacking += to be fast again because having the two loops below perform wildly differently is *very* surprising to me: s = '' for x in loops: s += x s = '' for x in loops: s = s + x Schiavo Simon ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Add a new builtin strarray type to Python?
On Sun, Oct 2, 2011 at 7:23 PM, Simon Cross wrote: > I'm -1 on hacking += to be fast again because having the two loops > below perform wildly differently is *very* surprising to me: > > s = '' > for x in loops: > s += x > > s = '' > for x in loops: > s = s + x Erk. Bad example. Second example should be: s = '' for x in loops: b = s s += x (I misunderstood the details but I new the reference counting hackiness would lead to surprises somewhere :). Schiavo Simon ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: Add a new builtin strarray type to Python?
Le dimanche 2 octobre 2011 15:25:21, Antoine Pitrou a écrit : > I don't know why you're saying that. The concatenation optimization > worked in 2.x where the "str" type also used only one memory block. You > just have to check that the refcount is about to drop to zero. > Of course, resizing only works if the two unicode objects are of the > same "kind". Oh, I see. In Python 2.7, bytes+=bytes calls PyMem_Realloc() on then writes the new characters to the result. It doesn't overallocate as bytearray (which overallocate +12,5%). I restored this hack in Python 3.3 using PyUnicode_Append() in ceval.c and by optimizing PyUnicode_Append() (try to append in-place). str+=str is closer again to ''.join: str += str: 696 ms ''.join(): 547 ms I disabled temporary the optimization for wstr string in PyUnicode_Resize() because of a bug. I disabled completly resize on Windows because of another bug. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
