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 may seem
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
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 native, b
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
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
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
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
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
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
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
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 = 123
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 -s x = 123 str('foobarbaz_%d') % x
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.
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
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 feel
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: What
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,
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 stdin, line 1, inmodule
TypeError: can't set attributes of built-in/extension type 'dict'
Hmm, yes,
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
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 better to freeze dict inplace
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?
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
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,
$ 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:
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:
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__ =
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
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?
___
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
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
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
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. ;)
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
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
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
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
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
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,
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
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.
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
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
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.
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
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
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
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
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 no overflow
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
On 18.05.12 21:30, Brian Curtin wrote:
On May 18, 2012 1:26 PM, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
At what point should we cut over docs.python.org
http://docs.python.org to point to the Python 3
documentation by default?
Today sounds good to me.
Yesterday. ;-)
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 string
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
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
On 19.06.12 15:13, Antoine Pitrou wrote:
sys.stdin
_io.TextIOWrapper name='stdin' 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
20.06.13 16:05, Christian Heimes написав(ла):
I have re-implemented the entire stat module in C. [1] It's a necessary
step to fix portability issues. For most constants POSIX standards
dictate only the name of the constant and its meaning but not its value.
Only the values of permission bits
Currently %c formatting raises OverflowError if an argument is out of range.
'%c' % 1114112
Traceback (most recent call last):
File stdin, line 1, in module
OverflowError: %c arg not in range(0x11)
'{:c}'.format(1114112)
Traceback (most recent call last):
File stdin, line 1, in module
29.06.13 18:16, Nadeem Vawda написав(ла):
I ran into the same problem in the _lzma module. My solution was to
define a custom converter that does an explicit check before returning
the value (see
http://hg.python.org/cpython/file/default/Modules/_lzmamodule.c#l134).
Definitely Argument Clinic
17.07.13 00:09, victor.stinner написав(ла):
http://hg.python.org/cpython/rev/533eb9ab895a
changeset: 84669:533eb9ab895a
user:Victor Stinner victor.stin...@gmail.com
date:Tue Jul 16 21:36:02 2013 +0200
summary:
Issue #18408: Fix fileio_read() on _PyBytes_Resize() failure
17.07.13 01:03, Victor Stinner написав(ла):
2013/7/16 Serhiy Storchaka storch...@gmail.com:
http://hg.python.org/cpython/rev/533eb9ab895a
summary:
Issue #18408: Fix fileio_read() on _PyBytes_Resize() failure
bytes is NULL on _PyBytes_Resize() failure
Why not Py_DECREF?
Because
16.07.13 20:21, Guido van Rossum написав(ла):
The situation is most egregious if the target string is a bytearray,
where there is currently no way to get the result as an immutable
bytes object without an extra copy. (There's no API that lets you
create a bytes object directly from a slice of a
What type of dash is preferable in the documentation? The en dash (–) or
the em dash (—)?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
18.07.13 20:48, Guido van Rossum написав(ла):
I believe there are only a few places where en-dashes should be used,
for most things you should use either em-dash or hyphen. Consult your
trusted typography source (for US English, please, punctuation
preferences vary by locale). E.g. Google for em
18.07.13 21:54, Brian Curtin написав(ла):
Besides visual consistency in a couple of places, is there a reason to
care enough to make a wholesale change?
Single hyphen instead of a dash just looks too ugly to me.
Trying to fix this I noticed that the documentation is inconsistent
regarding
18.07.13 21:55, Guido van Rossum написав(ла):
On Thu, Jul 18, 2013 at 11:46 AM, Serhiy Storchaka storch...@gmail.com wrote:
Or we should replace a half-dozen of em-dashes found in Python documentation
to en-dashes?
If my theory is right that makes sense. Especially if it's only a half-dozen
19.07.13 00:49, Ezio Melotti написав(ла):
On Thu, Jul 18, 2013 at 7:38 PM, Serhiy Storchaka storch...@gmail.com wrote:
What type of dash is preferable in the documentation? The en dash (–) or the
em dash (—)?
Both should be used where appropriate [0].
Of course I looked in Wikipedia before
19.07.13 07:51, Steven D'Aprano написав(ла):
Optimistically, I think it would probably be safe[1] to replace --
or --- in text with \N{THIN SPACE}\N{EM DASH}\N{THIN SPACE} (or
\N{HAIR SPACE} if you prefer) without human review, but for any other
changes, I wouldn't even try to automate it.
19.07.13 22:32, Ben Finney написав(ла):
Serhiy Storchaka storch...@gmail.com writes:
I'm asking only about this case, when the dash is used to denote a
break in a sentence or to set off parenthetical statements.
That's two separate cases:
* denote a break in a sentence
* set off
20.07.13 15:12, christian.heimes написав(ла):
http://hg.python.org/cpython/rev/c92f4172d122
changeset: 84723:c92f4172d122
user:Christian Heimes christ...@cheimes.de
date:Sat Jul 20 14:11:28 2013 +0200
summary:
Use strncat() instead of strcat() to silence some warnings.
CID
20.07.13 15:36, Antoine Pitrou написав(ла):
On Sat, 20 Jul 2013 15:23:46 +0300
Serhiy Storchaka storch...@gmail.com wrote:
20.07.13 15:12, christian.heimes написав(ла):
http://hg.python.org/cpython/rev/c92f4172d122
changeset: 84723:c92f4172d122
user:Christian Heimes christ
20.07.13 16:27, Christian Heimes написав(ла):
This will wrong when strlen(fname) is 30. strncat() will copy only 30
bytes, without terminal NUL.
That's not how strncat() works. strncat(dest, src, n) writes n+1 chars
to the end of dest: n chars from src and +1 for the final NUL char. For
this
I have opened an issue (http://bugs.python.org/issue18529) for patches.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Some tests uses the following idiom:
def test_main():
try:
test.support.run_unittest(...)
finally:
test.support.reap_children()
Other tests uses the following idiom:
def test_main():
key = test.support.threading_setup()
try:
12.08.13 22:22, Brett Cannon написав(ла):
I have created http://bugs.python.org/issue18716 to deprecate the
formatter module for removal in Python 3.6 unless someone convinces me
otherwise that deprecation and removal is the wrong move.
The formatter module doesn't look such buggy as the
15.08.13 01:07, Ethan Furman написав(ла):
From http://bugs.python.org/issue18738:
Actually the problem not only in IntEnum, but in any in subclass.
Currently for empty format specifier int.__format__(x, '') returns
str(x). But __str__ can be overloaded in a subclass. I think that for
less
15.08.13 06:23, Eli Bendersky написав(ла):
Yes, the problem here is certainly not IntEnum - specific; it's just
that IntEnum is the first for real use case of subclassing 'int' in
the stdlib.
Even not the first.
'{}'.format(True)
'True'
'{:10}'.format(True)
' 1'
22.08.13 02:59, victor.stinner написав(ла):
http://hg.python.org/cpython/rev/0a1e1b929665
changeset: 85308:0a1e1b929665
user:Victor Stinner victor.stin...@gmail.com
date:Thu Aug 22 01:58:12 2013 +0200
summary:
Cleanup test_builtin
files:
Lib/test/test_builtin.py | 16
22.08.13 14:48, Victor Stinner написав(ла):
You forgot self.addCleanup(unlink, TESTFN) (here and in other places).
These functions call write_testfile() which creates the file but also
schedules its removal when the test is done (since my changeset):
def write_testfile(self):
#
28.08.13 14:37, Victor Stinner написав(ла):
No, my question is: how can we detect that a test is never run? Do we
need test covertage on the test suite? Or inject faults in the code to
test the test suite? Any other idea?
Currently a lot of tests are skipped silently. See issue18702 [1].
08.09.13 20:52, Guido van Rossum написав(ла):
Well, to me zip(*x) is unnatural, and it's inefficient when the arrays are long.
Perhaps we need zip.from_iterable()?
___
Python-Dev mailing list
Python-Dev@python.org
There is a question about specifying the transform function.
There are three ways to do this:
1. Positional argument of the constructor.
d = TransformDict(str.casefold, Foo=5)
2. Subclassing.
class CaseInsensitiveDict(TransformDict):
def transform(self, key):
return
I work on enhancement of audio modules testing [1], and I need free (in
both senses) small sample audio files in different formats. We already
have audiotest.au (mono, and sunau has a bug in processing multichannel
files [2]) and Sine-1000Hz-300ms.aif, but this is not enough. I have
generated
11.09.13 12:52, Antoine Pitrou написав(ла):
Le Wed, 11 Sep 2013 12:38:13 +0300,
Serhiy Storchaka storch...@gmail.com a écrit :
2. Subclassing.
class CaseInsensitiveDict(TransformDict):
def transform(self, key):
return key.casefold()
d = CaseInsensitiveDict(Foo=5)
I thought
11.09.13 14:07, Antoine Pitrou написав(ла):
But I don't think the type generator API would be easier to implement
in C, anyway.
No, I mean subclassing approach.
___
Python-Dev mailing list
Python-Dev@python.org
11.09.13 16:50, Stephen J. Turnbull написав(ла):
Which modules in the stdlib would benefit from rewriting using
transformdict? How about on PyPI?
At least _threading_local, cProfile, doctest, json, and perhaps future
implementations of __sizeof__ for some classes would benefit from
11.09.13 15:45, Antoine Pitrou написав(ла):
If you want to edit, shorten, convert sounds between different formats,
you can try Audacity, a free sound editor:
http://audacity.sourceforge.net/
Yes, Audacity is great.
___
Python-Dev mailing list
11.09.13 15:46, Victor Stinner написав(ла):
Use your microphone, say python and save the file in your favorite
file format. Try for example Audacity. I suppose that you don't need
specific audio content and you don't need a huge file.
My voice is even more ugly than my English. I don't want
11.09.13 17:10, Oleg Broytman написав(ла):
Wouldn't his name be enough? http://www.python.org/~guido/guido.au
It is Lib/test/audiotest.au. 1-channel and 8-bit. No, it wouldn't enough.
___
Python-Dev mailing list
Python-Dev@python.org
11.09.13 17:10, Barry Warsaw написав(ла):
I have some pro-audio recording capabilities and would be happy to generate
some copyright-donated clips for Python. Please contact me off-list if
needed.
Thank you.
___
Python-Dev mailing list
13.09.13 21:40, Antoine Pitrou написав(ла):
Both are instances of a more general pattern, where a given
transformation function is applied to keys when looking them up: that
function being ``str.lower`` in the former example and the built-in
``id`` function in the latter.
Please use
13.09.13 21:40, Antoine Pitrou написав(ла):
Alternative proposals and questions
===
Yet one alternative proposal is to add the dict.__transform__() method.
Actually this not contradict TransformDict, but generalize it.
TransformDict will be just handly
13.09.13 23:02, Antoine Pitrou написав(ла):
On Fri, 13 Sep 2013 16:54:01 -0300
Joao S. O. Bueno jsbu...@python.org.br wrote:
I see the PEP does not contemplate a way to retrieve the original key
- like we've talked about somewhere along the thread.
Indeed. If that's important I can add it. I
13.09.13 22:37, Antoine Pitrou написав(ла):
That's true. But it's only important if TransformDict is the
bottleneck. I doubt the memoizing dictionary is a bottleneck in
e.g. the pure Python implementation of pickle or json.
It can be used in the C implementation.
13.09.13 23:21, Antoine Pitrou написав(ла):
On Fri, 13 Sep 2013 23:16:10 +0300
Serhiy Storchaka storch...@gmail.com wrote:
13.09.13 21:40, Antoine Pitrou написав(ла):
Alternative proposals and questions
===
Yet one alternative proposal is to add the dict
14.09.13 20:41, Antoine Pitrou написав(ла):
On Sat, 14 Sep 2013 09:43:13 -0700
Ethan Furman et...@stoneleaf.us wrote:
Still, I think it would be useful to expose the transform function.
Any good reason not to?
No good reason. What's the name? transform_func?
There is one reason --
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not transform_function or trans_func?
___
Python-Dev mailing list
Python-Dev@python.org
15.09.13 00:58, Antoine Pitrou написав(ла):
On Sun, 15 Sep 2013 00:55:35 +0300
Serhiy Storchaka storch...@gmail.com wrote:
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not transform_function or trans_func
15.09.13 14:23, Antoine Pitrou написав(ла):
On Sun, 15 Sep 2013 13:56:26 +0900
Larry Hastings la...@hastings.org wrote:
On 09/14/2013 07:30 PM, Antoine Pitrou wrote:
On Sat, 14 Sep 2013 14:33:56 +0900
Larry Hastings la...@hastings.org wrote:
Whenever I read a discussion about the dict, I
15.09.13 16:57, Antoine Pitrou написав(ла):
I don't really care. What's the point in the end? TransformDict is
non-trivial to implement, while the so-called TransformSet is just a
dict with a different API.
I don't see a difference. To me TransformDict is just a dict (or two).
02.10.13 20:31, Antoine Pitrou написав(ла):
On Wed, 2 Oct 2013 18:16:48 +0200 (CEST)
serhiy.storchaka python-check...@python.org wrote:
http://hg.python.org/cpython/rev/d48ac94e365f
changeset: 85931:d48ac94e365f
user:Serhiy Storchaka storch...@gmail.com
date:Wed Oct 02 19:15
Just some comments.
the first time time with a bit shift of 7
Double time.
with a 128bit seed and 64-bit output
Inconsistancy with hyphen. There are same issues in other places.
bytes_hash provides the tp_hash slot function for unicode.
Typo. Should be unicode_hash.
len =
1 - 100 of 1143 matches
Mail list logo
