> > Finally, my guess is that the Spanish emphasis on ñ as a separate
> > letter has to do with teaching how it has a separate position in the
> > localized collation sequence, doesn't it?
>
> You'd have to ask Mr. Gonzalez. I suspect he may have taught that way
> less because of his Castella
On Thu, 01 Sep 2011 12:38:07 -0700
Ethan Furman wrote:
> >
> > FWIW, I was taught that Spanish had 30 letters in the alfabeto: the
> > 'ñ', plus 'ch', 'll', and 'rr' were all considered distinct characters.
> >
> > Kids-these-days'ly,
>
> Not sure what's going on, but according to the article
On Fri, 02 Sep 2011 12:30:12 +1200
Greg Ewing wrote:
> Guido van Rossum wrote:
>
> > I recall long ago that when the french wrote words in all caps they
> > would drop the accents, e.g. ECOLE. I even recall (through the mists
> > of time) observing this in Paris on public signs. Is this still the
On Fri, 02 Sep 2011 19:53:37 +0200
Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/09/11 17:57, Jesus Cea wrote:
> > The build hangs or die with a "out of memory" error, eventually.
>
> A simple "make test" with python not compiled with "pydebug" and
> skipping all t
On Tue, 06 Sep 2011 01:53:32 +0200
victor.stinner wrote:
> http://hg.python.org/cpython/rev/b1e03d10391e
> changeset: 72297:b1e03d10391e
> user:Victor Stinner
> date:Tue Sep 06 01:53:03 2011 +0200
> summary:
> Issue #12567: Add curses.unget_wch() function
>
> Push a character
Michael Foord voidspace.org.uk> writes:
>
> Earlier this year I was at a pypy sprint helping to work on Python 2.7
compatibility. The bytearray type has much of the string interface, including
swapcase… So there was effort to implement this method with the correct
semantics for pypy. Doubtless th
Hello Martin,
> In the test suite, we have the bigmemtest and precisionbigmemtest
> decorators. I think bigmemtest cases should all be changed to
> precisionbigmemtest, giving sizes of just above 2**31. With that
> change, the runtime for test_capitalize would go down to 42s.
I have started work
For the record, I've disabled automatic builds on the bigmem buildbot
until things get sorted out a bit (no need to eat huge amounts of RAM
and eight hours of CPU each time a commit is pushed, only to have the
process killed :-)). It's still possible to run custom builds, of
course.
Regards
Anto
On Wed, 7 Sep 2011 10:47:16 +1000
Nick Coghlan wrote:
>
> However, a big +1 for deprecation in the case of bytes and bytearray.
> That's nothing to do with the maintenance burden though, it's to do
> with the semantic confusion between binary data and ASCII-encoded text
> implied by the retention
On Wed, 07 Sep 2011 13:38:23 +0200
Jesus Cea wrote:
>
> So, the problem is that a) "make test" takes quite a bit of RAM and b)
> the buildbot forks some "big" processes, so the virtual memory needed
> is BIG.
Note that buildbots run "make buildbottest", not "make test".
> So I have two question
On Wed, 07 Sep 2011 11:15:04 +0900
"Stephen J. Turnbull" wrote:
> Antoine Pitrou writes:
>
> > Bytes objects are often used for partly ASCII strings,
>
> All I can say to that phrase is, "urk, ISO 2022 anyone?"
You could also point out UTF-16 or EBCDIC,
Hello Jesus,
> I sorry to bother you with these details
> and waste of time, but could you possibly change my buildbot
> configurarion to launch, let's say, 4 test processes in parallel, just
> for testing?
Ok, I've added "-j4", let's how that works.
> Another option would be to have a single P
Le Fri, 09 Sep 2011 17:14:18 +0200,
Jesus Cea a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/09/11 09:18, Antoine Pitrou wrote:
> > Ok, I've added "-j4", let's how that works.
>
> It is not helping. it is taking tons of memory
Le Sat, 10 Sep 2011 05:02:09 +0200,
Jesus Cea a écrit :
>
> I have committed a few patches in the last hours to get my buildbots
> "green", back again. The memory used was <500MB, compared with >4GB
> before the "-j".
>
> Could you reconfigure my buildbots to be able to run all the six (2.7,
> 3
Le Fri, 23 Sep 2011 13:23:26 -0700,
Ethan Furman a écrit :
>
> So the question becomes, Why does it implement the Sequence ABC?
Because these operations are trivial to implement and it would be
suboptimal to have to instantiate the full list to run them?
_
On Sat, 01 Oct 2011 16:53:44 +0200
victor.stinner wrote:
> http://hg.python.org/cpython/rev/4afab01f5374
> changeset: 72565:4afab01f5374
> user:Victor Stinner
> date:Sat Oct 01 16:48:13 2011 +0200
> summary:
> Add _PyUnicode_UTF8() and _PyUnicode_UTF8_LENGTH() macros
>
> * R
On Sat, 01 Oct 2011 17:47:26 +0200
"Martin v. Löwis" wrote:
> Am 01.10.2011 17:18, schrieb Antoine Pitrou:
> > On Sat, 01 Oct 2011 16:53:44 +0200
> > victor.stinner wrote:
> >> http://hg.python.org/cpython/rev/4afab01f5374
> >> changeset: 72565:4a
On Sat, 1 Oct 2011 22:06:11 +0200
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).
>
> Hum, it looks like "What is the most efficient string concatenation method in
> python?" in a f
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
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.
>
> Th
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 "
Hello,
I am back from holiday ;) and we haven't heard from other
implementations whether there was any difficulty for them in
implementing PEP 3151. Did I miss something (it's difficult to keep up
with many messages on a small netbook with a screen broken by a
batman-like pattern obscuring the ri
On Mon, 3 Oct 2011 19:56:04 +0200
Antoine Pitrou wrote:
>
> Hello,
>
> I am back from holiday ;) and we haven't heard from other
> implementations whether there was any difficulty for them in
> implementing PEP 3151.
Alex Gaynor and Jim Baker (thank you!) just to
On Tue, 4 Oct 2011 13:05:58 -0400
Nick Coghlan wrote:
>
> > - _PyBytes_Resize() is missing; I moved it under a Py_LIMITED_API
> > section.
>
> No, that's not valid. Bytes are officially immutable - mutating them
> when the reference count is only 1 is a private for a reason. The
> correct way t
On Tue, 04 Oct 2011 21:33:34 +0200
"Martin v. Löwis" wrote:
> Am 04.10.11 21:06, schrieb Amaury Forgeot d'Arc:
> > 2011/10/4 "Martin v. Löwis":
> >>
> >>> - _PyBytes_Resize() is missing; I moved it under a Py_LIMITED_API
> >>>section.
> >>
> >> ??? Are you proposing to add _PyBytes_Resize to t
Le mercredi 05 octobre 2011 à 18:12 +0200, "Martin v. Löwis" a écrit :
> >> Not sure what you are using it for. If you need to extend the buffer
> >> in case it is too small, there is absolutely no way this could work
> >> without copies in the general case because of how computers use
> >> address
On Wed, 5 Oct 2011 09:38:10 -0700
Toshio Kuratomi wrote:
> On Wed, Oct 05, 2011 at 06:14:08PM +0200, Antoine Pitrou wrote:
> > Le mercredi 05 octobre 2011 à 18:12 +0200, "Martin v. Löwis" a écrit :
> > > >> Not sure what you are using it for. If you need to ext
On Thu, 6 Oct 2011 10:55:07 +1100
Cameron Simpson wrote:
>
> Equally, why on earth are you running tests as root!?!?!?!?! Madness.
> It's as bad as compiling stuff as root etc etc. A bad idea all around,
> securitywise.
>
> Especially, I would think, a builtbot. "Oh, let's fetch some shiny new
>
Hello,
The PyUnicode_KIND_SIZE macro is defined as follows. Its name looks
rather mysterious or misleading to me. Could we rename it to something
else?
(also, is it useful? PEP 393 has added a flurry of new macros to
unicodeobject.h and it's getting hard to know which ones are genuinely
useful, o
On Thu, 6 Oct 2011 10:06:17 -0500
Brian Curtin wrote:
> On Thu, Oct 6, 2011 at 09:12, Éric Araujo wrote:
> > Oh, let’s not forget naming. We can’t reuse the module name virtualenv
> > as it would shadow the third-party module name, and I’m not fond of
> > “virtualize”: it brings OS-level virtual
On Thu, 06 Oct 2011 17:52:05 +0200
Victor Stinner wrote:
> index << (kind - 1) and index * PyUnicode_CHARACTER_SIZE(str) were used
> in unicodeobject.c. It's not easy to understand this formula
index * PyUnicode_CHARACTER_SIZE(str)
is quite easy to understand to me.
I find it less cryptic tha
On Thu, 6 Oct 2011 12:02:05 -0400
Barry Warsaw wrote:
>
> >The first part is implemented in CPython; the second part needs a module
> >name to replace virtualenv. python -m pythonv doesn’t seem right.
>
> Nope, although `python -m virtualize` seems about perfect.
`python -m sandbox` ?
_
On Fri, 7 Oct 2011 08:27:01 +1100
Cameron Simpson wrote:
>
> 2: Root _can_ corrupt things anywhere in the system (within the VM, of
>course, but the builtbot is a subset of it). A normal unprivileged user
>will not have write permission to thing like:
> the OS image
> the compil
On Thu, 6 Oct 2011 17:40:20 -0400
Nick Coghlan wrote:
> On Thu, Oct 6, 2011 at 4:47 PM, Benjamin Peterson wrote:
> > Amaury Forgeot d'Arc gmail.com> writes:
> >
> >> I'd prefer it was written :
> >> if (PyUnicode_READY(*filename) < 0)
> >> because "< 0" clearly indicates an error conditio
On Fri, 7 Oct 2011 09:04:08 -0500
Brian Curtin wrote:
> On Fri, Oct 7, 2011 at 08:57, anatoly techtonik wrote:
> >> It's just that SimpleHTTPServer doesn't quite survive slashdot effect.
> >> Where do I fill a bug report :)
> >
> > http://bugs.python.org
>
> http://www.theonion.com/
Does theoni
On Sat, 8 Oct 2011 00:13:40 +0200
Maciej Fijalkowski wrote:
> On Fri, Oct 7, 2011 at 11:47 PM, Nick Coghlan wrote:
> > On Fri, Oct 7, 2011 at 4:50 PM, Maciej Fijalkowski wrote:
> >> Hi
> >>
> >> Can we disable by default disabling the cyclic gc in timeit module?
> >> Often posts on pypy-dev or o
> >
> > In CPython, looking for reference cycles is a parasitic task that
> > interferes with what you are trying to measure. It is not critical in
> > any way, and you can schedule it much less often if it takes too much
> > CPU, without any really adverse consequences. timeit takes the safe way
On Sat, 08 Oct 2011 17:14:55 +0200
Victor Stinner wrote:
> Le 08/10/2011 15:03, Antoine Pitrou a écrit :
> > On Fri, 07 Oct 2011 21:14:44 -0600
> > Jeffrey wrote:
> >> I would like to suggest adding an integer presentation type for base 36
> >> to PEP 3101. I
On Sat, 08 Oct 2011 16:54:06 +0200
"Martin v. Löwis" wrote:
>
> I find the ad-hoc approach of declaring and initializing variables
> inadequate, in particular since it is difficult to clean up all
> those string objects at interpreter shutdown.
>
> I propose to add an explicit API to deal with s
Ciao Giampaolo,
> I have a couple of doubts about this though.
> The first one is about licensing.
> What I would be doing is basically copy & paste pieces of the python
> stdlib modules (including tests) and, where needed, adjust them so
> that they work with older python versions.
> Would this
On Tue, 11 Oct 2011 09:19:43 -0400
Barry Warsaw wrote:
> On Oct 11, 2011, at 02:36 PM, Hrvoje Niksic wrote:
>
> >On 10/08/2011 04:54 PM, "Martin v. Löwis" wrote:
> >> tmp = PyObject_CallMethod(result, "update", "O", other);
> >>
> >> would be replaced with
> >>
> >>PyObject *tmp;
>
On Tue, 11 Oct 2011 18:22:43 -0400
Barry Warsaw wrote:
> As the BDFOP for PEP 3151, I hereby accept it for inclusion into Python 3.3.
>
> Congratulations to Antoine for producing a great PEP that has broad acceptance
> in the Python development community, with buy-in from all the major
> implemen
On Wed, 12 Oct 2011 00:53:52 +0200
victor.stinner wrote:
> http://hg.python.org/cpython/rev/2abd48a47f3b
> changeset: 72878:2abd48a47f3b
> user:Victor Stinner
> date:Wed Oct 12 00:54:35 2011 +0200
> summary:
> Backed out changeset 952d91a7d376
>
> If maxchar == PyUnicode_MAX_
Hello,
I'd like some advice on what the best path is in cases such as:
A :exc:`socket.error` is raised for errors from the call
to :func:`inet_ntop`.
Should I replace "socket.error" with "OSError" (knowing that the
former is now an alias of the latter), or leave "socket.error" so that
peo
On Thu, 13 Oct 2011 01:17:29 +0200
victor.stinner wrote:
> http://hg.python.org/cpython/rev/e5bd48b43a58
> changeset: 72903:e5bd48b43a58
> user:Victor Stinner
> date:Thu Oct 13 00:18:12 2011 +0200
> summary:
> Optimize findchar() for PyUnicode_1BYTE_KIND: use memchr and memrc
On Thu, 13 Oct 2011 14:00:38 +0200
"Martin v. Löwis" wrote:
> > I like this better too because of the all-caps macro name. Something about
> > seeing "Py_identifier" look like a function call and having it add the
> > magical
> > PyId_update local bugs me. It just looks wrong, whereas the all-c
On Thu, 13 Oct 2011 20:05:06 +0200
"Martin v. Löwis" wrote:
> > - In Modules/_json.c, line 1126, _Py_identifier(strict) is
> > declared but not used, and there are 5 other possible replacements.
>
> Antoine reverted this in 8ed6a627a834. I think I started doing them,
> then noticed that this is a
On Mon, 17 Oct 2011 02:04:38 +0200
Victor Stinner wrote:
> Le lundi 17 octobre 2011 01:16:36, Victor Stinner a écrit :
> > For example, IN.INT_MAX is 2147483647, whereas it should
> > be 9223372036854775807 on my 64-bit Linux.
>
> Oops, wrong example: INT_MAX is also 2147483647 on 64 bits. I me
Hello,
> I have been doing some performance experiments with memcmp, and I was
> surprised that memcmp wasn't faster than it was in Python. I did a whole,
> long analysis and came up with some very simple results.
>
> Before I put in a tracker bug report, I wanted to present my findings
> and
On Fri, 21 Oct 2011 08:24:44 +0200
Stefan Behnel wrote:
> Antoine Pitrou, 20.10.2011 23:08:
> >> I have been doing some performance experiments with memcmp, and I was
> >> surprised that memcmp wasn't faster than it was in Python. I did a whole,
> >> long
On Fri, 21 Oct 2011 18:23:24 + (GMT)
Richard Saunders wrote:
>
> If both loops are the same unicode kind, we can add memcmp
> to unicode_compare for an optimization:
>
> Py_ssize_t len = (len1
> /* use memcmp if both the same kind */
> if (kind1==kind2) {
> int result=me
Hello,
There are currently a bunch of various buildbot failures on all 3
branches. I would remind committers to regularly take a look at the
buildbots, so that these failures get solved reasonably fast.
Regards
Antoine.
___
Python-Dev mailing list
P
On Sat, 22 Oct 2011 20:30:34 +0100
Andrea Crotti wrote:
>
> In my previous workplace if someone broke a build committing something
> wrong he/she
> had to bring cake for everyone next meeting.
>
> The cake is not really feasible I guess, but isn't it possible to notify
> the developer that
>
> -1. If they were broken, and somebody used them, a bug would be
> reported. That no bug is being reported means that they either
> work fine, or nobody uses them.
>
> In the former case, removing them will break somebody's code.
> In the latter case, nothing is gained by either keeping or remov
On Mon, 24 Oct 2011 13:17:53 +0200
florent.xicluna wrote:
> @@ -2557,7 +2557,7 @@
> extend() -- extend array by appending multiple elements from an iterable\n\
> fromfile() -- read items from a file object\n\
> fromlist() -- append items from the list\n\
> -fromstring() -- append items from the
On Mon, 24 Oct 2011 15:58:11 +0300
Ezio Melotti wrote:
>
> I suggest to follow the following process:
>1) deprecate something and add a DeprecationWarning;
>2) decide how long the deprecation should last;
>3) use the deprecated-remove[1] directive to document it;
>4) add a test th
On Tue, 25 Oct 2011 00:57:42 +0200
Victor Stinner wrote:
> Hi,
>
> I propose to raise Unicode errors if a filename cannot be decoded on Windows,
> instead of creating a bogus filenames with questions marks. Because this
> change
> is incompatible with Python 3.2, even if such filenames are unu
On Fri, 28 Oct 2011 12:37:35 -0600
Carl Meyer wrote:
> What about include files?
> - -
>
> For example, ZeroMQ installs zmq.h and zmq_utils.h in $VE/include,
> whereas SIP (part of PyQt4) installs sip.h by default in
> $VE/include/pythonX.Y. With virtualenv, everything wor
On Sun, 30 Oct 2011 12:10:18 + (UTC)
Vinay Sajip wrote:
>
> > We already have Unix shell scripts and BAT files in the source tree. Is
> > it really complicated to maintain these additional shell scripts? Is
> > there a lot of code in them?
>
> No, they're pretty small: wc -l gives
>
> 76 po
On Sun, 30 Oct 2011 12:35:20 + (UTC)
Vinay Sajip wrote:
> The other alternative would be to make venv a package with all its code
> in venv/__init__.py and a scripts.zip adjacent to that. Does that seem
> like a better solution?
Please don't make it a zip file. We want code to be easily track
On Sun, 30 Oct 2011 13:38:35 +0100
petri.lehtinen wrote:
> http://hg.python.org/cpython/rev/f634102aca01
> changeset: 73204:f634102aca01
> parent: 73201:a5c4ae15b59d
> parent: 73203:b643458a0108
> user:Petri Lehtinen
> date:Sun Oct 30 14:35:39 2011 +0200
> summary:
>
On Sun, 30 Oct 2011 15:42:11 + (UTC)
Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>
> > Please don't make it a zip file. We want code to be easily trackable
> > and editable.
>
> Of course. I was thinking of a directory tree in the source,
On Sun, 30 Oct 2011 22:47:13 + (UTC)
Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>
> >
> > It would be even simpler not to process it at all, but install the
> > scripts as-is (without the execute bit) :)
> >
>
> Sure, but such an a
On Mon, 31 Oct 2011 07:50:24 + (UTC)
Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>
> > I don't understand why a zip file makes this easier (especially the
> > "update selectively" part).
>
> Not a zip file specifically - just a bina
On Mon, 31 Oct 2011 05:59:09 -0400
"Eric V. Smith" wrote:
>
> It might be true that such systems don't need binary packages on PyPI,
> but the original question is about binary package support for the
> packaging module on non-Windows systems. I think the answer is clearly
> "yes": I have such sy
On Mon, 31 Oct 2011 19:09:01 +0100
barry.warsaw wrote:
> http://hg.python.org/cpython/rev/1de4d92cd6a4
> changeset: 73258:1de4d92cd6a4
> branch: 2.7
> parent: 73253:7ce3b719306e
> user:Barry Warsaw
> date:Mon Oct 31 14:08:15 2011 -0400
> summary:
> test_protocol_sslv
On Tue, 1 Nov 2011 14:25:28 +0100
"Amaury Forgeot d'Arc" wrote:
> Hi,
>
> 2011/11/1 David Bailey
>
> > python-dev
> >
> > I am being forced to support multiple versions of python on Windows
> > platforms. I have been using PEP 397 and the execution of *.py files works
> > great. Thank you!!
> >
On Wed, 2 Nov 2011 19:41:30 -0700
Guido van Rossum wrote:
> Apparently Macports is still using a buggy compiler.
If I understand things correctly, this is technically not a buggy
compiler but Python making optimistic assumptions about the C standard.
(from issue11149: "clang (as with gcc 4.x) ass
On Thu, 03 Nov 2011 18:14:42 +0100
mar...@v.loewis.de wrote:
> There is a backwards compatibility issue with PEP 393 and Unicode exceptions:
> the start and end indices: are they Py_UNICODE indices, or code point indices?
>
> On the one hand, these indices are used in formatting error messages suc
On Thu, 03 Nov 2011 22:47:00 +0100
"Martin v. Löwis" wrote:
> >> On the one hand, these indices are used in formatting error messages such
> >> as
> >> "codec can't encode character \u%04x in position %d", suggesting they
> >> are regular
> >> indices into the string (counting code points).
>
Given it returns an eternal object, and it's almost always used
temporarily (for attribute lookup, string joining, etc.), it would seem
more practical for it to return a borrowed reference.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@pyth
Le 05/11/2011 17:34, Éric Araujo a écrit :
Hi Victor,
PyDict_GetItem() and PyDict_SetItem() don't call __getitem__ and __setitem__
for dict subclasses. Is there a reason for that?
http://bugs.python.org/issue10977 “Currently, the concrete object C API
bypasses any methods defined on subclasse
Le 06/11/2011 08:08, "Martin v. Löwis" a écrit :
Am 05.11.2011 23:26, schrieb Antoine Pitrou:
Given it returns an eternal object, and it's almost always used
temporarily (for attribute lookup, string joining, etc.), it would seem
more practical for it to return a borrowed r
On Sun, 6 Nov 2011 09:49:27 +0200
Petri Lehtinen wrote:
> list.index() and list.tuple() don't currently accept None as slice
> parameters, as reported in http://bugs.python.org/issue13340. For
> example:
>
> >>> [1, 2, 3].index(2, None, None)
> Traceback (most recent call last):
> File "", line
On Wed, 09 Nov 2011 10:44:50 +0100
"Martin v. Löwis" wrote:
> Am 09.11.2011 09:25, schrieb Stefan Behnel:
> > Stefan Behnel, 07.11.2011 18:46:
> >> Éric Araujo, 07.11.2011 18:24:
> http://hg.python.org/cpython/rev/bbc929bc2224
> >>>
> user: Philip Jenvey
> summary:
> quote the
On Tue, 08 Nov 2011 13:51:44 -0500
Terry Reedy wrote:
> On 11/8/2011 10:49 AM, Jesus Cea wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > When merging from 3.2 to 3.3 "Misc/NEWS" always conflicts (lately).
> > Instead of copy&paste the test manually between versions, has anybod
On Wed, 09 Nov 2011 23:21:35 +0100
Jesus Cea wrote:
>
> On 08/11/11 19:51, Terry Reedy wrote:
> > If a bug is fixed in 3.2.latest, then it will not be new in 3.3.0,
> > so perhaps it should not be added there. NEWS could just refer back
> > to previous sections. Then 3.3.0 News would only be new
On Thu, 10 Nov 2011 12:49:48 +0900
"Stephen J. Turnbull" wrote:
>
> > A bit of discipline and, voila, automatic flawless merges! :-)
>
> Doesn't work that way, sorry. The discipline required is isomorphic to
> that required by threaded programs. See multiple threads on
> python-ideas for why t
Hello everyone and Benjamin,
Currently, memoryview objects are unhashable:
>>> hash(memoryview(b""))
Traceback (most recent call last):
File "", line 1, in
TypeError: unhashable type: 'memoryview'
Compare with Python 2.7:
>>> hash(buffer(""))
0
memoryviews already support equality comparis
On Sat, 12 Nov 2011 17:15:08 -0800
Guido van Rossum wrote:
> Aren't memoryview objects mutable? I think that the underlying memory
> can change, so it shouldn't be hashable.
Only if the original object is itself mutable, otherwise the memoryview
is read-only.
I would propose the following algori
Thinking of it, an alternative would be to implement lazy slices of
bytes objects (Twisted uses buffer() for zero-copy slices).
Regards
Antoine.
On Sun, 13 Nov 2011 01:23:59 +0100
Antoine Pitrou wrote:
>
> Hello everyone and Benjamin,
>
> Currently, memoryview objects ar
On Sun, 13 Nov 2011 11:39:46 +0100
Stefan Krah wrote:
> Antoine Pitrou wrote:
> > Only if the original object is itself mutable, otherwise the memoryview
> > is read-only.
> >
> > I would propose the following algorithm:
> > 1) try to calculate the original obj
On Sun, 13 Nov 2011 13:05:24 +0100
Stefan Krah wrote:
> Nick Coghlan wrote:
> > > With slices or the new casts (See: http://bugs.python.org/issue5231,
> > > implemented in http://hg.python.org/features/pep-3118#memoryview ),
> > > it is possible to have different hashes for equal objects:
> >
>
On Sun, 13 Nov 2011 22:33:28 +0100
barry.warsaw wrote:
>
> +And Now For Something Completely Different
> +==
So, is the release manager a man with two noses?
> +Strings and bytes
> +-
> +
> +Python 2's basic original string type are calle
Hello,
I haven't seen any strong objections, so I would like to go ahead and
commit PEP 3155 (*) soon. Is anyone against it?
(*) "Qualified name for classes and functions"
http://www.python.org/dev/peps/pep-3155/
Thank you
Antoine.
___
Python-D
On Fri, 18 Nov 2011 18:15:28 -0500
Barry Warsaw wrote:
> On Nov 18, 2011, at 09:14 PM, Antoine Pitrou wrote:
>
> >I haven't seen any strong objections, so I would like to go ahead and
> >commit PEP 3155 (*) soon. Is anyone against it?
> >
> >(*) "
On Sat, 19 Nov 2011 03:31:09 +0100
Victor Stinner wrote:
> > I haven't seen any strong objections, so I would like to go ahead and
> > commit PEP 3155 (*) soon. Is anyone against it?
>
> I'm not against it, but I have some questions.
>
> Does you a working implementing?
I suppose the question i
On Sat, 19 Nov 2011 09:42:49 +0100
Stefan Behnel wrote:
> Hi,
>
> I recently got some patches accepted for inclusion in 3.3, and each time,
> the patch metadata (such as my name and my commit comment) were stripped by
> applying the patch manually, instead of hg importing it. This makes it
> c
On Sat, 19 Nov 2011 09:42:49 +0100
Stefan Behnel wrote:
>
> I didn't see this mentioned in the dev-guide. Is it being considered the
> Right Way To Do It?
That said, to answer your question more generally, I think it's simply
how we worked with SVN, and we haven't found any compelling reason to
On Mon, 21 Nov 2011 12:53:17 +0100
Victor Stinner wrote:
>
> I would like to add a new PyUnicode_AsWideChar() function which would return
> the borrowed reference, exactly as PyUnicode_AsUnicode(). The problem is that
> "PyUnicode_AsWideChar" already exists in Python 3.2, as
> PyUnicode_AsWide
On Mon, 21 Nov 2011 16:53:10 +0100
Victor Stinner wrote:
> Le Lundi 21 Novembre 2011 16:04:06 Antoine Pitrou a écrit :
> > On Mon, 21 Nov 2011 12:53:17 +0100
> >
> > Victor Stinner wrote:
> > > I would like to add a new PyUnicode_AsWideChar() function which w
On Mon, 21 Nov 2011 18:02:36 +0100
Victor Stinner wrote:
> Le Lundi 21 Novembre 2011 16:55:05 Antoine Pitrou a écrit :
> > > I want to rename PyUnicode_AsUnicode() and change its result type
> > > (Py_UNICODE* => wchar_t*). The result will be a "borrowed reference&
On Tue, 22 Nov 2011 13:38:03 +0100
giampaolo.rodola wrote:
> diff --git a/Misc/ACKS b/Misc/ACKS
> --- a/Misc/ACKS
> +++ b/Misc/ACKS
> @@ -11,7 +11,7 @@
> PS: In the standard Python distribution, this file is encoded in UTF-8
> and the list is in rough alphabetical order by last names.
>
> -Mat
On Tue, 22 Nov 2011 21:29:43 +0100
benjamin.peterson wrote:
> http://hg.python.org/cpython/rev/77ab830930ae
> changeset: 73697:77ab830930ae
> user:Benjamin Peterson
> date:Tue Nov 22 15:29:32 2011 -0500
> summary:
> fix compiler warning by implementing this more cleverly
You
On Tue, 22 Nov 2011 16:42:35 -0500
Benjamin Peterson wrote:
> 2011/11/22 Antoine Pitrou :
> > On Tue, 22 Nov 2011 21:29:43 +0100
> > benjamin.peterson wrote:
> >> http://hg.python.org/cpython/rev/77ab830930ae
> >> changeset: 73697:77ab830930ae
> >>
On Tue, 22 Nov 2011 19:42:24 -0500
Benjamin Peterson wrote:
> 2011/11/22 Antoine Pitrou :
> > On Tue, 22 Nov 2011 16:42:35 -0500
> > Benjamin Peterson wrote:
> >> 2011/11/22 Antoine Pitrou :
> >> > On Tue, 22 Nov 2011 21:29:43 +0100
> >> > benjam
On Tue, 22 Nov 2011 20:27:24 -0800
Raymond Hettinger wrote:
> >
> > But look! I'm already practicing: NO YOU CAN'T CHECK THAT IN. How's that?
> > Needs work?
>
> You could try a more positive leadership style: THAT LOOKS GREAT, I'M SURE
> THE RM FOR PYTHON 3.5 WILL LOVE IT ;-)
How about:
On Thu, 24 Nov 2011 20:15:25 +0200
Eli Bendersky wrote:
>
> Oops, readinto takes the same time as copying. This is a real shame,
> because readinto in conjunction with the buffer interface was supposed to
> avoid the redundant copy.
>
> Is there a real performance regression here, is this a well
On Thu, 24 Nov 2011 20:53:30 +0200
Eli Bendersky wrote:
>
> Sure. Updated the default branch just now and built:
>
> $1 -m timeit -s'import fileread_bytearray' 'fileread_bytearray.justread()'
> 1000 loops, best of 3: 1.14 msec per loop
> $1 -m timeit -s'import fileread_bytearray'
> 'fileread_byt
On Fri, 25 Nov 2011 12:02:17 +1100
Matt Joiner wrote:
> It's my impression that the readinto method does not fully support the
> buffer interface I was expecting. I've never had cause to use it until
> now. I've created a question on SO that describes my confusion:
>
> http://stackoverflow.com/q/
4101 - 4200 of 4909 matches
Mail list logo
