[Python-Dev] Re: Stable ABI question.

01.07.20 04:35, Inada Naoki пише: Hi, folks. I found PyEval_AcquireLock and PyEval_ReleaseLock are deprecated since Python 3.2. But the same time, stable ABI is defined in Python 3.2 too. The deprecated APIs are stable ABI too because `ceval.h` is not excluded from the stable ABI PEP. As far as

[Python-Dev] Re: Stable ABI question.

03.07.20 12:34, Victor Stinner пише: PyEval_ReleaseLock() is deprecated since Python 3.2 in the documentation: https://docs.python.org/dev/c-api/init.html#c.PyEval_ReleaseLock PyEval_AcquireLock() was annotated with Py_DEPRECATED() by Serhiy Storchaka in https://bugs.python.org/issue19569

[Python-Dev] Memory address vs serial number in reprs

I have problem with the location of hexadecimal memory address in custom reprs. vs The long hexadecimal number makes the repr longer and distracts attention from other useful information. We could get rid of it, but it is useful if we want to distinguish objects of the same type.

[Python-Dev] Re: Memory address vs serial number in reprs

19.07.20 19:33, Steven D'Aprano пише: On Sun, Jul 19, 2020 at 06:38:30PM +0300, Serhiy Storchaka wrote: What if use serial numbers to differentiate instances? I like this idea. It is similar to how Jython and IronPython object IDs work: # Jython >>> id(None)

[Python-Dev] Re: Memory address vs serial number in reprs

19.07.20 20:02, Guido van Rossum пише: That looks expensive, esp. for objects implemented in Python — an extra dict entry plus a new unique int object. What is the problem you are trying to solve for these objects specifically? Just that the hex numbers look distracting doesn’t strike me as suf

[Python-Dev] Re: Memory address vs serial number in reprs

19.07.20 23:30, Thomas Moreau пише: While it would be nice to have simpler identifiers for objects, it would be hard to make it work for multiprocessing, as objects in different interpreter would end up having the same repr. Shared objects (locks) might also have different serial numbers depend

[Python-Dev] Re: Memory address vs serial number in reprs

19.07.20 22:17, Antoine Pitrou пише: How about putting it in parentheses, to point more clearly that it can most of the time be ignored: It will just make the repr 2 characters longer and will not solve other problems (that first and last digits of the identifier of different objects usu

[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

04.09.20 13:40, Antoine Pitrou пише: > And tuple allocation uses freelists for small sizes, so I'm not even > sure how useful that optimization is. I do not know about zip(), but I measured the overhead of tuple allocation in comparison of reusing tuple in other code, and it was not so small. Tupl

[Python-Dev] Re: Enum and the Standard Library

19.09.20 00:44, Ethan Furman пише: > I'm looking for arguments relating to: > > - should _convert_ make the default __repr__ be module_name.member_name? In most cases enums with _convert_ are used to replace old module globals. They are accessible as module_name.member_name and always used as mod

[Python-Dev] Re: Understanding why object defines rich comparison methods

22.09.20 12:48, Steven D'Aprano пише: > Why does `object` define rich comparison dunders `__lt__` etc? > > As far as I can tell, `object.__lt__` etc always return NotImplemented. > Merely inheriting from object isn't enough to have comparisons work. So > why do they exist at all? Other "do nothi

[Python-Dev] Re: Enum and the Standard Library

22.09.20 16:57, Ethan Furman пише: > On 9/22/20 12:11 AM, Serhiy Storchaka wrote: >> The only exception is StrEnum -- overriding __str__ of str >> subclass may be not safe. Some code will call str() implicitly, other >> will read the string content of the object direc

[Python-Dev] Re: Understanding why object defines rich comparison methods

23.09.20 03:05, Greg Ewing пише: > On 23/09/20 12:20 am, Steven D'Aprano wrote: >> Presumably back when rich comparisons were added, the choice would have >> been: >> >> - add one tp_richcompare slot to support all six methods; or >> >> - add six slots, one for each individual dunder >> >> in which

[Python-Dev] Do we still need a support of non-type objects in issubclass()?

issubclass() accept types (extension types and new-style classes), classic classes and arbitrary objects with the __bases__ attribute as its arguments. The latter was added in issue464992 [1] to support the Zope extension ExtensionClass. I tested the current code of ExtensionClass [2], and seems i

[Python-Dev] Re: Do we still need a support of non-type objects in issubclass()?

03.10.20 12:45, Steven D'Aprano пише: > On Sat, Oct 03, 2020 at 11:41:16AM +0300, Serhiy Storchaka wrote: >> issubclass() accept types (extension types and new-style classes), >> classic classes and arbitrary objects with the __bases__ attribute as >> its arguments. &

[Python-Dev] Re: Do we still need a support of non-type objects in issubclass()?

03.10.20 18:15, Guido van Rossum пише: > Is this the only place where a non-class object with __bases__ is > accepted? Or do we have more such? I recall that long ago you could use > certain non-class objects as base classes. The only other place is object.__dir__(). It recursively iterates the __

[Python-Dev] Re: Do we still need a support of non-type objects in issubclass()?

04.10.20 01:06, Guido van Rossum пише: > On Sat, Oct 3, 2020 at 9:28 AM Serhiy Storchaka <mailto:storch...@gmail.com>> wrote: > The code of object.__dir__() is very old, it predates new-style classes, > and currently it gathers names using different algorithm than us

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

09.10.20 16:48, Antoine Pitrou пише: > Also, we now have an unmaintained module > (_decimal) requiring specific competence. It is not so bad. Due to high quality of the module there were not much changes in it in recent years, and many of them were cosmetic. We also have other Decimal experts. ___

[Python-Dev] Remove module's __version__ attributes in the stdlib

Some module attributes in the stdlib have attribute __version__. It makes sense if the module is developed independently from Python, but after inclusion in the stdlib it no longer have separate releases which should be identified by version. New changes goes into module usually without changing th

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

14.10.20 23:25, Batuhan Taskaya пише: > I've indexed a vast majority of the files from top 4K pypi packages to > this system, and here are the results about __version__ usage on > argparse, cgi, csv, decimal, imaplib, ipaddress, optparse, pickle, > platform, re, smtpd, socketserver, tabnanny (resul

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

14.10.20 23:25, Batuhan Taskaya пише: > I've indexed a vast majority of the files from top 4K pypi packages to > this system, and here are the results about __version__ usage on > argparse, cgi, csv, decimal, imaplib, ipaddress, optparse, pickle, > platform, re, smtpd, socketserver, tabnanny (resul

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

15.10.20 14:59, Victor Stinner пише: > 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). This is a good idea, I though about it. But it seems

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

14.10.20 20:56, Brett Cannon пише: > I think if the project is not maintained externally and thus synced into > the stdlib we can drop the attributes. I have found only one exception. decimal.__version__ refers to the version of the external specification which was not changed since 2009. I think

Re: [Python-Dev] Committing PEP 3155

19.11.11 01:54, Antoine Pitrou написав(ла): Well, the other propositions still seem worse to me. "Qualified" is reasonably accurate, and "qualname" is fairly short and convenient (I would hate to type "__qualifiedname__" or "__qualified_name__" in full). In the same vein, we have __repr__ which m

Re: [Python-Dev] [PATCH] Adding braces to __future__

10.12.11 13:14, francis написав(ла): Formatting is like food, everyone has it's own taste. One has to use spicery to change it (if possible). For me the view of the code (the layout) by the programmer should be automatically changed by the tool that reads the code. Here you could have a python wi

Re: [Python-Dev] readd u'' literal support in 3.3?

14.12.11 00:38, Nick Coghlan написав(ла): String translation is also an open question. For some codebases, you want both u"" and "" to translate to a Unicode "" (either in Py3k or via the future import), but if a code base deals with WSGI-style native strings (by means of u"" for text, "" for nat

Re: [Python-Dev] Hash collision security issue (now public)

05.01.12 21:14, Glenn Linderman написав(ла): So, fixing the vulnerable packages could be a sufficient response, rather than changing the hash function. How to fix? Each of those above allocates and returns a dict. Simply have each of those allocate and return and wrapped dict, which has the fo

Re: [Python-Dev] Hash collision security issue (now public)

06.01.12 02:10, Nick Coghlan написав(ла): Not a good idea - a lot of the 3rd party tests that depend on dict ordering are going to be using those modules anyway, so scattering our solution across half the standard library is needlessly creating additional work without really reducing the incompat

[Python-Dev] Hashing proposal: 64-bit hash

As already mentioned, the vulnerability of 64-bit Python rather theoretical and not practical. The size of the hash makes the attack is extremely unlikely. Perhaps the easiest change, avoid 32-bit Python on the vulnerability, will use 64-bit (or more) hash on all platforms. The performance is co

Re: [Python-Dev] Hashing proposal: 64-bit hash

27.01.12 23:08, Frank Sievertsen написав(ла): As already mentioned, the vulnerability of 64-bit Python rather theoretical and not practical. The size of the hash makes the attack is extremely unlikely. Unfortunately this assumption is not correct. It works very good with 64bit-hashing. It's mu

Re: [Python-Dev] Hashing proposal: 64-bit hash

27.01.12 23:08, Frank Sievertsen написав(ла): As already mentioned, the vulnerability of 64-bit Python rather theoretical and not practical. The size of the hash makes the attack is extremely unlikely. Unfortunately this assumption is not correct. It works very good with 64bit-hashing. It's mu

Re: [Python-Dev] best place for an atomic file API

15.02.12 23:16, Charles-François Natali написав(ла): Issue #8604 aims at adding an atomic file API to make it easier to create/update files atomically, using rename() on POSIX systems and MoveFileEx() on Windows (which are now available through os.replace()). It would also use fsync() on POSIX to

Re: [Python-Dev] PEP 414

26.02.12 11:05, Vinay Sajip написав(ла): The PEP does not consider an alternative idea such as using "from __future__ import unicode_literals" in code which needs to run on 2.x, together with e.g. a callable n('xxx') which can be used where native strings are needed. This avoids the need to reint

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

Some microbenchmarks: $ python -m timeit -n 1 -r 100 -s "x = 123" "'foobarbaz_%d' % x" 1 loops, best of 100: 1.24 usec per loop $ python -m timeit -n 1 -r 100 -s "x = 123" "str('foobarbaz_%d') % x" 1 loops, best of 100: 1.59 usec per loop $ python -m timeit -n 1 -r 100 -s "x =

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

26.02.12 14:42, Armin Ronacher написав(ла): On 2/26/12 12:35 PM, Serhiy Storchaka wrote: Some microbenchmarks: $ python -m timeit -n 1 -r 100 -s "x = 123" "'foobarbaz_%d' % x" 1 loops, best of 100: 1.24 usec per loop $ python -m timeit -n 1 -r 100 -

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

27.02.12 22:19, Terry Reedy написав(ла): Since "u" and "U" will go away again some year, they should only be used for such multi-version code and not in code only intended for Python 3. See PEP 414. And not for code intended for both Python 2 and Python 3.0-3.2. ___

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

28.02.12 00:11, Armin Ronacher написав(ла): On 2/27/12 9:58 PM, R. David Murray wrote: But the PEP doesn't address the unicode_literals plus str() approach. That is, the rationale currently makes a false claim. Which would be exactly what that u() does not do? No. 1. u() is trivial for Pytho

Re: [Python-Dev] PEP 414

28.02.12 00:52, Barry Warsaw написав(ла): On Feb 27, 2012, at 10:38 PM, Armin Ronacher wrote: Indeed I have three other PEPs in the work. The reintroduction of "except (((ExceptionType),),)", the"<>" comparision operator and the removal of "nonlocal", the latter to make Python 2.x developers fe

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

28.02.12 14:14, Nick Coghlan написав(ла): > However, that's the wrong question. > The right question is "Does PEP 414 make porting substantially > *easier*, by significantly reducing the volume of code that needs to > change in order to attain Python 3 compatibility?". Another pertinent question:

Re: [Python-Dev] Add a frozendict builtin type

01.03.12 01:52, Victor Stinner написав(ла): Problem: if you implement a frozendict type inheriting from dict in Python, it is still possible to call dict methods (e.g. dict.__setitem__()). To fix this issue, pysandbox removes all dict methods modifying the dict: __setitem__, __delitem__, pop, etc

Re: [Python-Dev] Add a frozendict builtin type

01.03.12 11:11, Victor Stinner написав(ла): You can redefine dict.__setitem__. Ah? It doesn't work here. dict.__setitem__=lambda key, value: None Traceback (most recent call last): File "", line 1, in TypeError: can't set attributes of built-in/extension type 'dict' Hmm, yes, it's true.

Re: [Python-Dev] Add a frozendict builtin type

01.03.12 11:29, André Malo написав(ла): - Caching. My data container objects (say, resultsets from a db or something) usually inherit from list or dict (sometimes also set) and are cached heavily. In order to ensure that they are not modified (accidentially), I have to choices: deepcopy

Re: [Python-Dev] Add a frozendict builtin type

01.03.12 16:47, André Malo написав(ла): > On Thursday 01 March 2012 15:17:35 Serhiy Storchaka wrote: >> This is the first rational use of frozendict that I see. However, a deep >> copy is still necessary to create the frozendict. For this case, I >> believe, would be be

Re: [Python-Dev] PEP 414

02.03.12 15:49, Lennart Regebro написав(ла): Just my 2 cents on the PEP rewrite: u'' support is not just if you want to write code that doesn't use 2to3. Even when you use 2to3 it is useful to be able to flag strings s binary, unicode or "native". What "native" means in context Python 3 only?

Re: [Python-Dev] PEP 414

03.03.12 08:20, Lennart Regebro написав(ла): But you are right, it isn't necessary. I was thinking of 3to2, actually. That was one of the objections I had to the usefulness of 3to2, there is no way to make the distinction between unicode and native strings. (The u'' prefix hence actually makes 3t

Re: [Python-Dev] PEP 414

04.03.12 00:12, "Martin v. Löwis" написав(ла): 2to3 should recognize the str(string_literal) (or nstr(), or native(), etc) ​​as a native string and does not add prefix "u" to it. And you have to explicitly specify these tips. That is already implemented. 2to3 *never* adds a u prefix anywhere, i

Re: [Python-Dev] Sandboxing Python

$ python execfile.py badhash.py Hang up. class badhash: __hash__ = int(42).__hash__ set([badhash() for _ in range(10)]) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.py

Re: [Python-Dev] Sandboxing Python

There is even easier way to exceed the time-limit timeout and to eat CPU: sum(xrange(10)). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/

Re: [Python-Dev] Sandboxing Python

05.03.12 23:16, Victor Stinner написав(ла): > Apply the timeout would require to modify the sum() function. sum() is just one, simple, example. Any C code could potentially run long enough. Another example is the recently discussed hashtable vulnerability: class badhash: __hash__ = int(42)._

Re: [Python-Dev] Sandboxing Python

05.03.12 23:47, Guido van Rossum написав(ла): Maybe it would make more sense to add such a test to xrange()? (Maybe not every iteration but every 10 or 100 iterations.) `sum([10**100]*100)` leads to same effect. ___ Python-Dev mailing list Py

Re: [Python-Dev] What letter should an UnsignedLongLong get

15.03.12 21:59, Gil Colgate написав(ла): How about 'G'? (Giant, or perhaps gynormous, integer?) Then I could also map 'g' to the signed version (same as L) for consistency. What about unsigned char, short, int, and long with overflow checking? ___

Re: [Python-Dev] What letter should an UnsignedLongLong get

15.03.12 21:59, Gil Colgate написав(ла): How about 'G'? (Giant, or perhaps gynormous, integer?) Then I could also map 'g' to the signed version (same as L) for consistency. For consistency 'g' must be `unsigned long` with overflow checking. And how about 'M'? 'K', 'L', and 'M' are neighborin

Re: [Python-Dev] Python install layout and the PATH on win32

17.03.12 13:57, Paul Moore написав(ла): As there is no way of knowing the Python version without running Python, this is too slow to be practical. Cold start: $ time python3 --version Python 3.1.2 real0m0.073s user0m0.004s sys 0m0.004s Hot start: $ time python3 --version Python 3.

Re: [Python-Dev] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)

17.03.12 17:00, Guido van Rossum написав(ла): One reason to use 'bytes' instead of bytes is that it is a string that can be specified e.g. in a config file. Thus, there are no reasons to use bytes instead of 'bytes'. ___ Python-Dev mailing list Pytho

Re: [Python-Dev] Playing with a new theme for the docs

21.03.12 14:38, Ned Batchelder написав(ла): The best thing to do is to set a max-width in ems, say 50em. This leaves the text at a reasonable width, but adapts naturally for people with larger fonts. It's good for books, magazines, and newspapers, but not for technical site. ;) _

Re: [Python-Dev] Playing with a new theme for the docs

21.03.12 03:58, Ned Batchelder написав(ла): Books, magazines, and newspapers look good with full justification, web pages do not. Can we switch to left-justified instead? You can add line p {text-align: left !important} to your browser custom stylesheet. If you are using Firefox or Chrome (C

Re: [Python-Dev] Playing with a new theme for the docs

21.03.12 16:18, Ned Batchelder написав(ла): We could just as easily choose to make the site left-justified, and let the full-justification fans use custom stylesheets to get it. I find justified text convenient and pleasant for the eyes. Many people hate left-aligned text. I think that the bes

Re: [Python-Dev] Playing with a new theme for the docs

If I can get my five cents, I will tell about my impressions. I really liked the background of allocated blocks (such as notes and code snippets) has become less diverse (but still visible). The border around these blocks have become more accurate and more pleasant to emphasize blocks. It is ve

Re: [Python-Dev] Playing with a new theme for the docs

21.03.12 18:00, Guido van Rossum написав(ла): (Can you see why I invented a whitespace-sensitive language? I have a whitespace-sensitive brain. :-) It should be added to favorite quotes. ___ Python-Dev mailing list Python-Dev@python.org http://mail.p

Re: [Python-Dev] Playing with a new theme for the docs, iteration 2

25.03.12 09:34, Georg Brandl написав(ла): Here's another try, mainly with default browser font size, more contrast and collapsible sidebar again: It may be worth now the line-height reduce too? I've also added a little questionable gimmick to the sidebar (when you collapse it and expand it ag

Re: [Python-Dev] Playing with a new theme for the docs, iteration 2

25.03.12 11:06, Peter Otten написав(ла): * Inlined code doesn't need the gray background. The bold font makes it stand out enough. I believe that the gray background is good, but it should make it lighter. * Instead of the box consider italics or another color for [New in ...] text. Yes, th

Re: [Python-Dev] Playing with a new theme for the docs, iteration 2

25.03.12 09:34, Georg Brandl написав(ла): I've also added a little questionable gimmick to the sidebar (when you collapse it and expand it again, the content is shown at your current scroll location). I'm not sure if this is possible, and how good it would look like, but I have one crazy idea.

[Python-Dev] PEP 393 decode() oddity

PEP 393 (Flexible String Representation) is, without doubt, one of the pearls of the Python 3.3. In addition to reducing memory consumption, it also often leads to a corresponding increase in speed. In particular, the string encoding now in 1.5-3 times faster. But decoding is not so good. Here

Re: [Python-Dev] PEP 393 decode() oddity

25.03.12 20:01, Antoine Pitrou написав(ла): The general problem with decoding is that you don't know up front what width (1, 2 or 4 bytes) is required for the result. The solution is either to compute the width in a first pass (and decode in a second pass), or decode in a single pass and enlarge

Re: [Python-Dev] PEP 393 decode() oddity

26.03.12 01:28, Victor Stinner написав(ла): Cool, Python 3.3 is *much* faster to decode pure ASCII :-) He even faster on large data. 1000 characters is not enough to completely neutralize the constant costs of the function calls. Python 3.3 is really cool. encoding string

Re: [Python-Dev] PEP 393 decode() oddity

27.03.12 01:04, Serhiy Storchaka написав(ла): 26.03.12 01:28, Victor Stinner написав(ла): loop in cascade of independent loops which fallback onto each other (as you have already done in utf8_scanner). Sorry. Not you. Antoine Pitrou. ___ Python-Dev

Re: [Python-Dev] PEP 393 decode() oddity

25.03.12 23:55, mar...@v.loewis.de написав(ла): The results are fairly stable (±0.1 µsec) from run to run. It looks funny thing. This is not surprising. Thank you. Indeed, it is logical. I looked at the code and do not see how to speed it up. ___

Re: [Python-Dev] datetime module and pytz with dateutil

28.03.12 23:20, Andrew Svetlov написав(ла): I figured out what pytz and dateutil are not mentioned in python docs for datetime module. It's clean why these libs is not a part of Python Libraries — but that's not clean for Docs. I don't understand why Python may not include the pytz. The Olson t

Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.

Andrew, when you prepare the tkinter documentation, I advise you to include a link to www.tkdocs.com -- probably the best resource in this way (at least it was very useful for me). Maybe even should offer these guys do official documentation, if they agree and if there would be no conflict of

Re: [Python-Dev] Optimize Unicode strings in Python 3.3

04.05.12 02:45, Victor Stinner написав(ла): * Two steps: compute the length and maximum character of the output string, allocate the output string and then write characters. str%args was using it. * Optimistic approach. Start with a ASCII buffer, enlarge and widen (to UCS2 and then UCS4) the

Re: [Python-Dev] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()

07.05.12 14:35, Mark Dickinson написав(ла): Hmm. Very clever, but it's not obvious that that overflow check is mathematically sound. My fault. Overflow will be at PY_SSIZE_T_MAX congruent to 4 modulo 5 (which is impossible if PY_SSIZE_T_MAX is one less than a power of 2). Mathematically str

Re: [Python-Dev] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()

07.05.12 18:48, Serhiy Storchaka написав(ла): My fault. However, it's not my fault. I suggested `newlen < (PY_SSIZE_T_MAX - PY_SSIZE_T_MAX / 5)` and not `newlen <= (PY_SSIZE_T_MAX - PY_SSIZE_T_MAX / 5)`. In this case, there is

[Python-Dev] void* <-> size_t

On 13.05.12 12:48, Stefan Krah wrote: The C standard doesn't guarantee sizeof(void *) == sizeof(size_t). In fact, there are machines where sizeof(void *)> sizeof(size_t): http://comments.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/651 http://www-01.ibm.com/support/docview.wss?ui

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

On 18.05.12 21:30, Brian Curtin wrote: On May 18, 2012 1:26 PM, "Barry Warsaw" mailto:ba...@python.org>> wrote: > At what point should we cut over docs.python.org to point to the Python 3 > documentation by default? Today sounds good to me. Yesterday. ;-) Issue14469

Re: [Python-Dev] Optimize Unicode strings in Python 3.3

On 30.05.12 01:44, Victor Stinner wrote: The "two steps" method is not promising: parsing the format string twice is slower than other methods. The "1.5 steps" method is more promising -- first parse the format string in an efficient internal representation, and then allocate the output strin

Re: [Python-Dev] [Python-checkins] cpython: Issue #14744: Use the new _PyUnicodeWriter internal API to speed up str%args

On 29.05.12 19:55, Victor Stinner wrote: The following changesets should fix the two errors, but not warnings. Why not move `TYPE *p` declaration inside WRITE_DIGITS? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/li

Re: [Python-Dev] Optimize Unicode strings in Python 3.3

On 30.05.12 14:26, Victor Stinner wrote: I implemented something like that, and it was not efficient and very complex. See for example the (incomplete) patch for str%args attached to the issue #14687: http://bugs.python.org/file25413/pyunicode_format-2.patch I have seen and commented on this p

Re: [Python-Dev] Help to fix this bug http://bugs.python.org/issue15068

On 19.06.12 15:13, Antoine Pitrou wrote: sys.stdin <_io.TextIOWrapper name='' mode='r' encoding='UTF-8'> So it's a TextIOWrapper from the _io module (which is really the implementation of the io module). You'll find its source in Modules/_io. TextIOWrapper objects are defined in Modules/_io/tex

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On 16.07.12 10:36, Stefan Behnel wrote: Return values could be -1 for "don't know" and -2 for "infinite" at the C level, and NotImplemented for "don't know" at the Python level. PY_SSIZE_T_MAX is better value for "infinite". In any case no difference for consumer between PY_SSIZE_T_MAX and a r

Re: [Python-Dev] io.BytesIO slower than monkey-patching io.RawIOBase

On 17.07.12 06:34, Eli Bendersky wrote: The second approach is consistently 10-20% faster than the first one (depending on input) for trunk Python 3.3 Is there any reason for this to be so? What does BytesIO give us that the second approach does not (I tried adding more methods to the patched Ra

Re: [Python-Dev] cpython (merge 3.2 -> default): MERGE: Better test for Issue #15402: Add a __sizeof__ method to struct.Struct

On 23.07.12 19:38, Jesus Cea wrote: The problem is that if we do ">=", then an unpatched python interpreter could pass the test too. So we are not actually testing the feature. If the repeat counters are going to be optimized, the obvious step would be to upgrade the test to do something like "B

Re: [Python-Dev] cpython (merge 3.2 -> default): MERGE: Better test for Issue #15402: Add a __sizeof__ method to struct.Struct

On 23.07.12 21:19, Meador Inge wrote: The patch was out for review for several days ... Actually for several months (in issue14596). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: ht

Re: [Python-Dev] cpython (merge 3.2 -> default): MERGE: Better test for Issue #15402: Add a __sizeof__ method to struct.Struct

On 23.07.12 22:46, Michael Foord wrote: I am now prepared a set of 14 __sizeof__ patches (should it be one issue or 14 individual issues in bugtracker?), and I feel a great desire not to write tests at all. Without tests how can you have any confidence the patches are correct (or will contin

Re: [Python-Dev] cpython (merge 3.2 -> default): MERGE: Better test for Issue #15402: Add a __sizeof__ method to struct.Struct

On 24.07.12 00:44, mar...@v.loewis.de wrote: 42 is most likely not the right answer, as the size should be a multiple of four. >>> ''.__sizeof__() 25 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

[Python-Dev] __sizeof__ tests

I have a set of patches about the correct __sizeof__ implementations (one has already been committed (issue #15456), 13 left, 2 of them published (#15469 for deque and #15475 for itertools)). The most tedious is to write tests for them, especially paranoid tests, on which Martin v. Löwis insist

Re: [Python-Dev] __sizeof__ tests

On 28.07.12 12:58, Chris Jerdonek wrote: This is nearly the same as the question I asked below about feature freeze (or that I was trying to ask), to which I thought I received an answer different from the one stated above: Thank you, Chris. ___ Pyt

Re: [Python-Dev] cpython: Fix findnocoding.p and pysource.py scripts

On 01.08.12 21:16, victor.stinner wrote: http://hg.python.org/cpython/rev/67d36e8ddcfc changeset: 78375:67d36e8ddcfc user:Victor Stinner date:Wed Aug 01 20:12:51 2012 +0200 summary: Fix findnocoding.p and pysource.py scripts I suppose that these scripts didn't work since Py

Re: [Python-Dev] Understanding the buffer API

On 04.08.12 17:51, Nick Coghlan wrote: I took Jeff's question as being slightly different and applying in the following situations: 1. If the consumer has NOT requested format data, can the provider return accurate format data anyway, if that's easier than returning NULL but is consistent with d

Re: [Python-Dev] cpython (3.2): open() / TextIOWrapper doc: make it explicit than newline='\n' doesn't

On 04.08.12 02:27, victor.stinner wrote: http://hg.python.org/cpython/rev/243ad1a6f638 changeset: 78403:243ad1a6f638 branch: 3.2 parent: 78400:f19bea7bbee7 user:Victor Stinner date:Sat Aug 04 01:18:56 2012 +0200 summary: open() / TextIOWrapper doc: make it explicit

Re: [Python-Dev] 3.3 str timings

On 19.08.12 00:17, Terry Reedy wrote: This is one of the 3.3 improvements. But since the results are equal: ('a'*1000).encode() == ('a'*1000).encode(encoding='utf-8') and 3.3 should know that for an all-ascii string, I do not see why adding the parameter should double the the time. Another issue

Re: [Python-Dev] Release of astoptimizer 0.3

On 11.09.12 13:41, Victor Stinner wrote: Here are some progress on my astoptimizer project. If you are interested by the optimizer, run it on your own project or help me to implement more optimizations. http://pypi.python.org/pypi/astoptimizer https://bitbucket.org/haypo/astoptimizer It's a ve

Re: [Python-Dev] Release of astoptimizer 0.3

On 12.09.12 00:47, Victor Stinner wrote: set([x for ...]) => {x for ...} dict([(k, v) for ...]) => {k: v for ...} dict((k, v) for ...) => {k: v for ...} ''.join([s for ...]) => ''.join(s for ...) a.extend([s for ...]) => a.extend(s for ...) These optimizations look correct. Actually generator

Re: [Python-Dev] Release of astoptimizer 0.3

On 12.09.12 00:47, Victor Stinner wrote: x = x + [y] => x.append(y) x = x + [y, z] => x.extend([y, z]) It behaves differently if x is not a list, but str for example. Actually even worse. Transformations applicable only if x has not aliases. Pseudocode: if type(x) is list and refcount(x)

[Python-Dev] Deprecating "U" open mode

Since Python 2.3 many open-like functions supports "Universal line mode" (PEP 278 [1]). Since 3.0 (and 2.6) PEP 3116 [2] suggests better alternative -- io.TextWrapper. In issue15204 [3] proposed to deprecate "U" mode in open-like functions. In fact I found only three places where "U" mode is m

Re: [Python-Dev] Stdlib and timezones, again

On 30.09.12 16:15, Antoine Pitrou wrote: Probably, but for most purposes I would guess a 2-year old database is still good enough? After all, you don't see many people complaining about the outdated Unicode database that is hard-wired in past Pythons. In 2011 Ukrainian timezone data was changed

Re: [Python-Dev] Stdlib and timezones, again

On 30.09.12 22:24, Antoine Pitrou wrote: Just because some governments have erratic policies shouldn't be a reason for residents of other countries not to enjoy the benefits of their stable timezones. This is similar to ascii-chauvinism. ;-) ___ Pyt

Re: [Python-Dev] Stdlib and timezones, again

On 30.09.12 22:51, Antoine Pitrou wrote: Well, no, this isn't similar. Choosing one's timezone policies is a contemporary political decision, while choosing a language and its alphabet is not really a decision people ever make (it's just an aspect of a society's long-term evolution) - except Atat

Re: [Python-Dev] cpython: utilize yield from

On 01.10.12 22:54, philip.jenvey wrote: http://hg.python.org/cpython/rev/fb90e2ff95b7 changeset: 79378:fb90e2ff95b7 user:Philip Jenvey date:Mon Oct 01 12:53:43 2012 -0700 summary: utilize yield from This is not all. diff -r fb90e2ff95b7 Lib/http/cookiejar.py --- a/Lib/htt

[Python-Dev] Should vars() return modifiable dict?

For objects with __dict__ vars() returns modifiable dict: >>> class A(): ... pass ... >>> a = A() >>> a.x = 42 >>> vars(a) {'x': 42} >>> vars(a)['x'] = 43 >>> vars(a)['y'] = 44 >>> a.x, a.y, vars(a) (43, 44, {'y': 44, 'x': 43}) For globals vars() returns modifiable dict: >>> x = 42 >>> vars

Re: [Python-Dev] Proposed schedule for Python 3.4

On 03.10.12 19:02, Larry Hastings wrote: But my suspicion is that most people who try the alphas are doing early integration testing with their own stuff. For those people, the earlier the alpha, the less interesting it probably is to them. Earlier means that the software will be less finished.

Re: [Python-Dev] Proposed schedule for Python 3.4

On 03.10.12 20:10, MRAB wrote: I downloaded the alphas to test the support for PEP 393 I'd added to the regex module. Hardly alpha would be useful to you if it released before PEP 393 implementation. ___ Python-Dev mailing list Python-Dev@python.o

<    6   7   8   9   10   11   12   >