> I'm not really complaining (the API fixes are long overdue), just
> leaving a comment that what a compiler considers a warning or error
> pretty much depends on compiler, platform and configuration.
No no no. It does *not* depend on compiler, platform, or configuration.
It *only* depends on the
> I'm afraid I don't follow you. Unless you're suggesting some sort of
> esoteric object system whereby objects *don't* have identity (e.g. where
> objects are emergent properties of some sort of distributed,
> non-localised "information"), any object naturally has an identity --
> itself.
Not in
Am 04.12.2010 09:48, schrieb Eli Bendersky:
> To build the trunk Python 3k, it seems that Python 2 has to be installed.
> This is because Objects/typeslots.py is called in the Makefile, and this
> file uses Python 2 "print statement" syntax, which fails if $(PYTHON) is
> actually Python 3.
This sh
> Surely even in Java or C#, objects have an *identity* even if the
> language doesn't provide a way to query their distinct *identification*.
When people said "the id of an object should this or that", they always
meant identification, not identity (perhaps except for you). Nobody
would propose t
> Why is useful to expose an identity hash? AFAICS it is *only* useful
> in building an identity hash table. If so, why not just provide id()
> or the is operator or both and be done with it?
That's precisely James' point: Java provides the identity hash
*instead* of the id() function (i.e. it d
> At the language summit it was proposed and seemed generally accepted (maybe
> I took silence as consent... it's been almost a year now) that bold new
> modules (and bold rewrites of existing modules since it fell out of the
> distutils/2 discussion) should get implemented in a module on pypi befo
> 1. Parts of the Makefile that use Python checked if Python is installed
> and generate a useful error if not.
> 2. All Python scripts that are part of the build should be 2-vs-3
> version agnostic for the time being (= until Python 2 is distant
> history, which won't happen soon)
I think this is
> I actually wonder if Python's re module can claim to provide even
> Basic Unicode Support.
Do you really wonder? Most definitely it does not.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
I'd like to tighten PEP 11, and declare a policy that systems
older than ten years at the point of a feature release are not
supported anymore by default. Older systems where support is still
maintained need to be explicitly listed in the PEP, along with
the name of the responsible maintainer (I th
>> The other major system affected by this would be Windows 2000, for which
>> we already decided to not support it anymore.
>
> Is there any 2000-specific code (as opposed to XP-compatible)?
Yes: a number of APIs didn't exist in W2k, so we currently use
LoadLibrary/GetProcAddress to call them. T
Am 06.12.2010 05:36, schrieb Nick Coghlan:
> On Mon, Dec 6, 2010 at 7:48 AM, "Martin v. Löwis" wrote:
>> I'd like to tighten PEP 11, and declare a policy that systems
>> older than ten years at the point of a feature release are not
>> supported anymore by def
Am 06.12.2010 09:36, schrieb Jeroen Ruigrok van der Werven:
> -On [20101206 08:30], "Martin v. Löwis" (mar...@v.loewis.de) wrote:
>> As a counter-example, I think the only way to phase out support
>> for old OpenBSD releases is that we set a date.
>
> If you want, I
> EOL dates of prominent Linux distribution :
I think I would need more information than that. Nick's proposal was
more specific: when does the vendor stop producing patches? This is
a clear criterion, and one that I support.
> RHEL:
> https://access.redhat.com/support/policy/updates/errata/
My
Am 06.12.2010 13:18, schrieb Ulrich Eckhardt:
> On Saturday 04 December 2010, Antoine Pitrou wrote:
>> Perhaps SVN doesn't get timestamps right.
>
> SVN doesn't touch timestamps explicitly, it just writes the files as they
> come
> and the system gives them the timestamps. This also makes sense,
Am 06.12.2010 14:40, schrieb Floris Bruynooghe:
> On 6 December 2010 09:18, "Martin v. Löwis" wrote:
>>> Also, it is not clear what to do about distributions/OSs
>>> without any official EOL or life cycles.
>>
>> Here my proposal stands: 10 years,
> FWIW, transform()/untransform() are already in the 3.2 beta.
> Do you want them taken out? If so, do you want the codecs
> made accessible with encode/decode or have them continue
> to be inaccessible in 3.x?
Notice that they wouldn't be inaccessible even if transform
is taken out again: codec
Am 06.12.2010 20:25, schrieb Terry Reedy:
> On 12/6/2010 4:08 AM, "Martin v. Löwis" wrote:
>
>> For Windows and Solaris, it seems that some users continue to use the
>> system after the vendor stops producing patches, and dislike the
>> prospect of not hav
>> So by this policy, RHEL and SuSE users would be off worse than with
>> my original proposal (10 years).
>
> Red Hat continues to provide patches for RHEL within the "Extended Life
> Cycle" (years 8, 9 and 10), but it's an optional add-on.
My understanding is that you keep the patches available
Am 07.12.2010 04:03, schrieb Alexander Belopolsky:
> On Sat, Dec 4, 2010 at 5:58 PM, "Martin v. Löwis" wrote:
>>> I actually wonder if Python's re module can claim to provide even
>>> Basic Unicode Support.
>>
>> Do you really wonder? Most definite
Am 09.12.2010 03:56, schrieb MRAB:
> The regex module calls _PyUnicode_IsWhitespace, which is mapped by
> unicodeobject.h to either _PyUnicodeUCS2_IsWhitespace or
> _PyUnicodeUCS4_IsWhitespace.
>
> From Python 2.5 to Python 3.1 the library pythonXX.lib contains either
> _PyUnicodeUCS2_IsWhitespace
Am 09.12.2010 13:49, schrieb Hirokazu Yamamoto:
> On 2010/11/25 1:23, exar...@twistedmatrix.com wrote:
>> Ah. Okay, then Python 3.2 would be vulnerable. Good thing it isn't
>> released yet. ;)
>
> It seems OpenSSL 1.0.0c out.
>
> http://openssl.org/news/secadv_20101202.txt
>
>> 02-Dec-2010:
Am 09.12.2010 06:57, schrieb Alexander Belopolsky:
> On Thu, Dec 9, 2010 at 12:47 AM, "Martin v. Löwis" wrote:
> ..
>>> However, in Python 3.2b1 the library python32.lib contains only
>>> _PyUnicode_IsWhitespace, therefore breaking the build.
>>>
>
> Comments?
How do you implement that? In particular, how do you retrieve
information for different locales in a single program?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
Am 18.12.2010 19:55, schrieb Alexander Belopolsky:
> On Sat, Dec 18, 2010 at 11:50 AM, Georg Brandl wrote:
> ..
>> In any case, this is coming pretty late; beta 2 is scheduled for this
>> weekend, and even if this is something that only kicks in when all hope
>> is lost anyway, it is a new feature
Am 18.12.2010 19:26, schrieb MRAB:
> On 18/12/2010 09:26, "Martin v. Löwis" wrote:
>>> Comments?
>>
>> How do you implement that? In particular, how do you retrieve
>> information for different locales in a single program?
>>
> The locale m
> I suppose there could be some sort of locale database. A downloadable,
> up-to-date copy of the database could be maintained on the Python
> website.
I think you are quite underestimating the implementation effort.
So -0 on your original proposal until such a thing actually exists.
Regards,
Mar
>> This is also what I think. Installing a signal handler is a fairly
>> drastic action, and I don't think the code has been sufficiently
>> reviewed yet.
>
> How much more review should it receive?
There should be at least one reviewer with an established track record
of being interested/knowled
> Functions used by the fault handler:
> - write()
> - PyUnicode_Check()
> - PyFrame_GetLineNumber()
> - DebugBreak() (Windows, in debug mode, only)
> - abort()
> - (macro) PyUnicode_GET_SIZE() and PyUnicode_AS_UNICODE()
> - PyUnicode_Check(), PyFrame_Check()
> - PyFrame_GetLineNumber()
>
> What? Is it a myth or does Python really support multiple interpreters
> in the same process? How is it possible? Who uses this?
[Not sure if you are joking]
There is certainly some support for multiple interpreters in Python; the
most prominent user of this feature is mod_python.
Regards,
Mar
>> Looking at your function list, my other concern is that you are calling
>> Python API without holding the GIL, IIUC. In particular, you are
>> accessing _PyThreadState_Current, which may not point to the current
>> thread if the current thread has released the GIL.
>
> Ah? Where does _PyThreadS
>> Do you have an example bug where this patch helps in finding the precise
>> location of a segfault?
>
> How is 'line 29 in g' not more precise than 'Segmentation fault'?
I think Stefan is treating "precise location" as an absolute property,
not a relative one. The precise location would be the
>> The GIL is likely held by a different thread, then.
>> _PyThreadState_Current will point to the state of this other thread.
>
> I tested when the GIL released: the fault handler is unable to retrieve "the"
> thread state and so the backtrace is not printed. Which thread state should
> be
> r
> Given the changing dynamics of the desktop launch menus to better
> support direct access as an alternative to hierarchical navigation,
> would it be reasonable to consider including the major version number
> in the start menu shortcut names?
>
> (Question is mainly for Martin, obviously, but I
> So, do you agree with the fault handler? Does someone want to give a
> last review because I commit it?
It's a new feature, so regardless of whether it's correct or not
(which I haven't reviewed yet), I don't think it should go in before
3.2 is released.
Regards,
Martin
> The fault handler is disabled by default and it is clearly separated
> (eg. it doesn't touch the API of a module). Can't you make an exception
> for this new feature?
Ultimately, it's for the release manager to decide, so I don't need to
make an exception. However, I think that special cases are
> Horrible or not, the existence of __attribute__(signal) seems to
> indicate that this is the case on some platform, or at least was
> historically.
The signal attribute has an effect only on ATMEL AVR processors,
according to the documentation (and according to my source grep).
On other processo
Am 23.12.2010 22:09, schrieb Éric Araujo:
> Le 23/12/2010 20:55, Antoine Pitrou a écrit :
>>> def __index__(self):
>>> -"""index(self)"""
>>> +"""someobject[self]"""
>>
>> This is misleading as to what the method actually does,
> Really? Unless I misunderstood the docs, __inde
> # "a?b:c" to "test(a,b,c)".
> expr = re.compile(r'(.*?)\?(.*?):(.*)')
> def repl(x):
> -return "test(%s, %s, %s)" % (x.group(1), x.group(2),
> - expr.sub(repl, x.group(3)))
> +return "(%s if %s else %s)" % (x.group(2), x.group(1),
> What are the actual used of .__index__?
Can you please rephrase this question?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/py
Am 28.12.2010 11:28, schrieb Victor Stinner:
> Le lundi 27 décembre 2010 à 23:07 -0500, R. David Murray a écrit :
>> On Mon, 27 Dec 2010 02:49:27 +0100, victor.stinner
>> wrote:
>>> Author: victor.stinner
>>> Date: Mon Dec 27 02:49:26 2010
>>> New Revision: 87504
>>>
>>> Log:
>>> Issue #9738: Doc
> I think it would be nice to have Windows equivalents (GetPriorityClass
> / SetPriorityClass) as well but I'm not sure how since their notation
> is different.
I don't mind exposing it (somewhere), however, it should keep its
original name. In addition, you probably need OpenProcess, as well
as
Am 28.12.2010 18:08, schrieb Lukas Lueg:
> Also, the
> load_fast in lne 22 to reference x could be taken out of the loop as x
> will always point to the same object
That's not true; a debugger may change the value of x.
Regards,
Martin
___
Python-De
>> I would like to know if it should be considered as a release blocker.
>> Georg Brandl said yes on IRC.
>
> Under the condition that it is within reason to fix it before the
> release.
What *should* be possible is to disable building
SemLock/multiprocessing.synchronize on FreeBSD. As a conseque
> Hi all, What Victor says above is correct, although I wasn't aware
> that POSIX IPC under FreeBSD 7.2 was still having problems. Prior to
> 7.2 it was broken but 7.2 worked OK in my limited testing. In any
> case, the sysv_ipc module is mine and it's mature and you're welcome
> to pillage it in w
Am 29.12.2010 18:54, schrieb Jesse Noller:
> On Wed, Dec 29, 2010 at 10:28 AM, "Martin v. Löwis"
> wrote:
>>>> I would like to know if it should be considered as a release blocker.
>>>> Georg Brandl said yes on IRC.
>>>
>>> Under t
>> If you can make the above change, the question then is what API
>> multiprocessing semaphores should be built upon. It seems that you
>> are saying that they should use SysV IPC, and only fall back to
>> POSIX IPC if SysV IPC doesn't work/exist (are there any platforms
>> where this would be
>>> The multiprocessing test suite already skips the tests which use the
>>> (broken) functionality on BSD correctly. This logic needs to be added
>>> to the concurrent.futures library.
>> Also, what specific test are you referring to?
Can you kindly point me to the test that skips if broken funct
> If the functionality is not supported then users get an import error
> (within multiprocessing). However, RDM's understanding is correct, and
> the test is creating more than supported.
Hmm. The tests do the absolute minimum stuff that exercises the code;
doing anything less, and they would be u
Am 29.12.2010 22:34, schrieb Jesse Noller:
>
>
> On Dec 29, 2010, at 3:49 PM, "Martin v. Löwis" wrote:
>
>>> If the functionality is not supported then users get an import error
>>> (within multiprocessing). However, RDM's understanding is co
> I don't have a good suggestion (or a computer with a keyboard
> anywhere near me) right now, but making a migration/fallback to SYSV
> style semaphores a release blocker seems like a mistake to me.
And indeed, I don't propose to make that a release blocker. Instead,
I propose to disable support
Am 30.12.2010 04:45, schrieb Brian Quinlan:
> On Dec 29, 2010, at 2:55 PM, Victor Stinner wrote:
>
>> Le mercredi 29 décembre 2010 à 21:49 +0100, "Martin v. Löwis" a écrit :
>>> Of course, one may wonder why test_first_completed manages
>>> to create 41 Sem
Am 30.12.2010 16:40, schrieb Antoine Pitrou:
> On Thu, 30 Dec 2010 16:04:16 +0100
> Łukasz Langa wrote:
>>
>> Some answers Philip gave already. Knowing all these things would let us
>> decide whether switching the module off on systems that don't meet the
>> requirements is okay and can we get a
> And, again, the threading-based API in concurrent.futures should work
> fine anyway. Do you suggest we selectively disable the process-based
> API?
Yes. Importing concurrent.futures.process should fail. Unfortunately,
it's imported from __init__.py, so either we change the API to move
the execut
> 1. Does it still fail on FreeBSD 7.3+?
Yes, it still fails. The limits (30 semaphores) haven't
changed. It also remains untunable.
> 2. Why is the semaphore limit so low in the first place?
I don't know - (Free)BSD is in the tradition of disliking
SysV inventions, and POSIX inventions unless t
Am 30.12.2010 18:54, schrieb Stephen J. Turnbull:
> R. David Murray writes:
>
> > I thought Amaury was saying it was harder than svnmerge, not harder
> > than patching by hand (ie: that it *was* patching by hand, including
> > .rej files and the lack of tracking). I also heard Georg say that t
> Also, it's not really necessary for everyone to merge every change from
> maintenance to trunk: a) they can do multiple commits on the same
> subject and merge once, and b) if the change is small and no problems can
> be expected from merging, merging can also be done by others, just like
> the m
Am 30.12.2010 20:57, schrieb Éric Araujo:
> Hi,
>
> One thing confuses me in this thread: Do the problems come from merging
> across different versions (i.e. different syntax and module names), or
> are they regular problems that come up because people don’t want to use
> a merge tool?
Neither n
Am 30.12.2010 21:36, schrieb Ethan Furman:
> Martin v. Löwis wrote:
>>> And, again, the threading-based API in concurrent.futures should work
>>> fine anyway. Do you suggest we selectively disable the process-based
>>> API?
>>
>> Yes. Importing concurr
> BTW - can anyone contribute data points from other *BSDs?
I don't have an installation of OpenBSD, but...
In FreeBSD, POSIX semaphores are implemented in sys/kern/uipc_sem.c.
In
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/
that file doesn't exist. Also, in FreeBSD's limits.h,
_POSIX_SE
> I added informations about FreeBSD, NetBSD, Darwin and OpenBSD to the
> issue #10348:
> http://bugs.python.org/issue10348#msg125042
>
> The maximum number of POSIX semaphores can be read with sysctl:
> - FreeBSD: "p1003_1b.sem_nsems_max"
> - NetBSD: "kern.posix.semmax"
> - Darwin: "kern.posix
Am 05.01.2011 12:48, schrieb yeswanth:
> Hello everyone,
> My name is Yeswanth . I am doing my third year Btech in Computer Science
> in India. My desire is to get into gsoc 2011 . I have been looking over
> the projects of last year to see where I would fit in. And I found
> python to be interesti
> BTW: I've been doing gcc pre-release testing regularly for many year,
> starting
> with gcc 3.3. This is the first time I see the Python build fail persistently
> for several weeks.
Wild guess: did configure detect that it needs to use -fno-strict-aliasing?
Regards,
Martin
__
Am 09.01.2011 21:31, schrieb Antoine Pitrou:
> On Sun, 9 Jan 2011 11:17:40 -0800
> Guido van Rossum wrote:
>> Isn't that just shutil.copyfileobj()?
>
> copyfileobj() still uses an user-space buffer (the Python bytes
> object used in the loop). The advantage of sendfile() is to bypass
> user-spac
> Maybe that could be fixed? Then the remaining feature would be a way
> to sort issue lists by number of nosy people, and to display the
> length of the nosy list.
http://bugs.python.org/iss...@action=search&@columns=title,id,nosy_count&status=1&@sort=-nosy_count
You can create an URL like this
> I don't want Python to encourage people to use non-ascii module names.
I don't think the feature is open for debate anymore. PEP 3131 has been
accepted (after *long* debates), and I'll pronounce that supporting
non-ASCII module names is a direct consequence of having it accepted.
Of course, the
>> I don't think anybody is *encouraging* it. The argument is for
>> *permitting* it, partly for consistency with other identifiers, and
>> partly because of Python's usual "consenting adults" standard for
>> permitting "dangerous" practices.
>
> I'm sorry, I was not clear. I was afraid that sayi
> Adding an extra set of quotes around the command seems to fix
> this. I've attached a patch.
This is puzzling: a) AFAICT, the code works on all other system as it
stands, and b) putting this many quotes into the command line is not
plausible.
Do you have any strange settings on your compute
Am 22.01.2011 19:16, schrieb yeswanth:
> I would want to help porting some web framework for py3k .. I want to
> know to know which one is good and which can be ported easily . Also i
> would require some guidance for this work as I am just a beginner here ..
Yeswanth,
Terry already indicated tha
> ""c:\path\to\subwcrev.exe" arg1 arg2 ..." just works. I don't understand
> why (strange syntax), but it works :-)
>
> When I had the problem, it worked with extra quotes, but not without. It
> is strange because the program ("c:\path\to\subwcrev.exe") existed!?
I'd really like to understand it
> I am still curious why a previous exception changed pickle behavior, and
> only in 3.2, but I would rather you fix another bug than speeding much
> time to get me up to speed on the intricacies of _pickle ;-).
IIUC, the code change made pickle actually aware of the exception,
rather than just se
> > Really? I would have thought that cell phones have long been the
> > platforms most supportive of Unicode.
>
> I would think so too, except in Japan.
>
> However, my previous phones exposed file systems with names encoded in
> Shift JIS to USB and IR browsers, though. (My current one uses
s/pep-0393/
For convenience, I include it below.
Regards,
Martin
PEP: 393
Title: Flexible String Representation
Version: $Revision: 88168 $
Last-Modified: $Date: 2011-01-24 21:14:21 +0100 (Mo, 24. Jan 2011) $
Author: Martin v. Löwis
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
C
Am 24.01.2011 16:39, schrieb Victor Stinner:
> Le lundi 24 janvier 2011 11:35:22, Stephen J. Turnbull a écrit :
>> ... VFAT-formatted file systems and Shift JIS file names ...
>
> I missed something: VFAT stores filenames as unicode (whereas FAT only
> supports byte filenames). Well, VFAT stores
> If that pattern is a goal, having all versions of the namespace's
> __init__.py empty of anything but the __path__-munging majyk /
> boilerplate is required to make such installs work regardless of the
> order of PYTHONPATH.
With PEP 382, having extensible packages won't contradict to having
a n
>> I'd like to propose PEP 393, which takes a different approach,
>> addressing both problems simultaneously: by getting a flexible
>> representation (one that can be either 1, 2, or 4 bytes), we can
>> support the full range of Unicode on all systems, but still use
>> only one byte per character f
>> This isn't a critical issue (nothing is broken) but we're a week
>> from another release candidate, so the new Py3.2 package
>> organization (unittest was flat in Py3.1 and its test were under
>> Lib/test) is about to become a de-facto decision that will be hard
>> to undo.
>
> Well can we stop
> Some comments would be nice. Right now it looks pretty close to
> deliberately obfuscated code (especially with the call to
> gc.get_referrers()).
That call tries to get at the class dictionary, rather then just
the dict_proxy that you get from A.__dict__. There should be
two referrers to thingy
Am 26.01.2011 10:40, schrieb Victor Stinner:
> Le lundi 24 janvier 2011 à 19:26 -0800, Toshio Kuratomi a écrit :
>> Why not locale:
>> * Relying on locale is simply not portable. (...)
>> * Mixing of modules from different locales won't work. (...)
>
> I don't understand what you are talking about
> If NFSv3 doesn't reencode filenames for each client and the clients
> don't reencode filenames, all clients have to use the same locale
> encoding than the server. Otherwise, I don't see how it can work.
In practice, users accept that they get mojibake - their editors can
still open the files, a
>When switching to a UTF-8 locale, they can also change the file
> names of their modules to be encoded in UTF-8. It would be fairly easy
> to write a script that identifies non-ASCII file names in a directory
> and offers to transcode their names from their current encoding to
> UTF-8.
In fac
> So, the only criticism I have, intuitively, is that the unicode
> structure seems to become a bit too large. For example, I'm not sure you
> need a generic (pointer, size) pair in addition to the
> representation-specific ones.
It's not really a generic pointer, but rather a variable-sized point
> I believe the intent this pep is aiming at is for the existing in
> memory structure to be compatible with already compiled binary
> extension modules without having to recompile them or change the APIs
> they are using.
No, binary compatibility is not achieved. ABI-conforming modules will
conti
> Repetition of "11"; I'm guessing that the 2byte/UCS-2 should read "10",
> so that they give the width of the char representation.
Thanks, fixed.
>> 00 => null pointer
>
> Naturally this assumes that all pointers are at least 4-byte aligned (so
> that they can be masked off). I assume that t
Am 25.01.2011 12:08, schrieb Nick Coghlan:
> On Tue, Jan 25, 2011 at 6:17 AM, "Martin v. Löwis" wrote:
>> A new function PyUnicode_AsUTF8 is provided to access the UTF-8
>> representation. It is thus identical to the existing
>> _PyUnicode_AsString, which is removed
>>From my first impression, I'm
> not too thrilled by the prospect of making the Unicode implementation
> more complicated by having three different representations on each
> object.
Thanks, added as a concern.
> I also don't see how this could save a lot of memory. As an example
> take a French
Am 27.01.2011 20:06, schrieb Stefan Behnel:
> "Martin v. Löwis", 24.01.2011 21:17:
>> The Py_UNICODE type is still supported but deprecated. It is always
>> defined as a typedef for wchar_t, so the wstr representation can double
>> as Py_UNICODE representatio
Am 27.01.2011 21:38, schrieb Brett Cannon:
> Because of all the writing I have been doing lately, I have been
> pulling up a lot of URLs pointing to various Python releases based
> around minor versions (e.g., Python 2.7, not specifically 2.7.1). What
> has been somewhat annoying is that there are
> I agree. After all, CPython is lucky to have it available. It wouldn't
> be the first time that we duplicate looping code based on the input
> type. However, like the looping code, it will also complicate all
> indexing code at runtime as it always needs to test which of the
> representations is
> Whatever we do, let's use this opportunity to unify redirect rules
> for http://www.python.org/X.Y and http://docs.python.org/X.Y. For a
> related discussion, see http://bugs.python.org/issue10446.
TLDR; somebody should summarize it and specify what exactly needs to
be changed.
I'm only going
> Works for me! Short and elegant.
Done!
http://www.python.org/2.6.x
http://www.python.org/2.x
http://www.python.org/3.1.x
http://www.python.org/3.x
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
Am 27.01.2011 23:53, schrieb Stefan Behnel:
> "Martin v. Löwis", 24.01.2011 21:17:
>> If the string is created directly with the canonical representation
>> (see below), this representation doesn't take a separate memory block,
>> but is allocated right after t
> The nice thing about Py_UNICODE is that is basically gives you native
> Unicode code points directly, without needing to decode UTF-8 byte runs
> and the like. In Cython, it allows you to do things like this:
>
> def test_for_those_characters(unicode s):
> for c in s:
> #
>> None of the functions in this PEP become part of the stable ABI.
>
> I think that's only part of the truth. This PEP can potentially have an
> impact on the stable ABI in the sense that the build-time size of
> Py_UNICODE may no longer be important for extensions that work on
> unicode buffers
> Python 3.1 does already test many filenames, but with Python 3.2, it is
> even worse.
>
> For each directory in sys.path, it tries 9 suffixes: '',
> '.cpython-32m.so', 'module.cpython-32m.so', '.abi3.so',
> 'module.abi3.so', '.so', 'module.so', '.py', '.pyc'.
>
> I don't understand why it tests
Am 30.01.2011 17:54, schrieb Alexander Belopolsky:
> On Sun, Jan 30, 2011 at 11:35 AM, Victor Stinner
> wrote:
> ..
>> We should find a compromise between speed (limit the number of system
>> calls) and the usability of Python modules.
>
> Do you have measurements that show python spending signif
> Maybe also
>
>* Read and cache the directory contents and search it ourselves
> instead of making a system call for every possible name.
I wouldn't do that - I would expect that this is actually slower than
making the system calls, because the system might get away with not
reading the
> Another thing to consider: on App Engine (which despite of all its
> architectural weirdness uses a -- mostly -- standard Linux filesystem
> for the Python code of the app) someone measured that importing from a
> zipfile is much faster than importing from the filesystem. I would
> imagine this e
Am 31.01.2011 22:13, schrieb anatoly techtonik:
> Ok. Here is the patch. I used Orca to reverse installer tables of
> Mercurial MSI and inserted similar entry for Python.
This doesn't do uninstallation correctly.
Regards,
Martin
___
Python-Dev mailing l
>> If you don't want to receive a stupid answer, why don't you read the
>> link and say what you don't like in this approach in a constructive
>> manner?
>
> As I understand it, there used to be patc...@python.org. I'm not sure
> why this was discontinued, so perhaps someone more senior should chi
> It is a surprise to find builtin msilib. Why isn't it used?
Originally, because Python needs to be packaged with an older
release (in particular one that isn't itself maintained anymore).
Today, the problem is that the msilib package doesn't support
merge modules (and if such support was added,
2201 - 2300 of 5277 matches
Mail list logo
