I think this problem probably needs to move over to distutils-sig, as
it doesn't seem to be specific to the way that Python itself uses
distutils. distutils.command.build_ext tests for Py_ENABLE_SHARED on
linux and solaris and automatically adds '.' to the library_dirs, and
I suspect it just needs
On Wed, Jan 6, 2010 at 17:21, "Martin v. Löwis" wrote:
>> b) Does this fix seem like the sensible thing to do?
>
> No. Linking in setup.py should use the same options as if the module
> was built as *shared* through Modules/Setup, which, IIUC, should use
> BLDLIBRARY.
Thanks for that pointer, tha
On Wed, Jan 6, 2010 at 16:14, Nicholas Bastin wrote:
> This of course is because libpython2.7.so is in the current directory
> and not (yet) installed in /usr/local/lib.
One minor correction - as you could see from the compile line, the
actual --prefix in this case is /u1/tmp/python2.7a
(This may occur on more platforms - I can test on more unix platforms
if the consensus is this is an actual problem and I'm not just a nut)
On freebsd5, if you do a simple ./configure --enable-shared in current
(2.7) trunk, your python shared library will build properly, but all
modules will fail
On 10/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I keep getting regular requests from people looking for Python coders
> (and this is in addition to Google asking me to hand over my contacts
> :-). This is good news because it suggests Python is on the uptake
> (always good to know). At t
On 10/3/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > For stack frames,
> > such a registration is difficult to make efficient.
>
> Also very error-prone if you happen to miss one. Although
> maybe no more error-prone than getting the reference
> counting right.
Maybe, but
Might expected skips instead be based on your current configuration
instead of what someone statically decided what would be appropriate
for your platform? Every new release I have to go through the
'unexpected skips' to determine that they're perfectly fine for how I
configured python.
It seems
On 3/6/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 07:24 PM 3/6/2007 +0100, Martin v. Löwis wrote:
> >given a list of file names, classify them for display (the
> > way the Windows explorer works, and similar file managers).
> > They use MIME databases and the like, and if they are
I've fixed it. It appears that there was something wrong with
Pageant, and removing my key and readding it solved the problem. The
lack of any debugging info from subversion was very helpful in solving
this problem.. :-)
Thanks for the help from those who responded.
--
Nick
On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> You could try to do
>
> ssh -vv [EMAIL PROTECTED]
>
> and see if the debug messages mean anything to you.
My problem is that SSH works fine if you just try to do that (well,
with plink). It's subversion that doesn't seem to be working.
--
Nick
I've had to blast my windows machine, as one is apparently required to
do on occasion, and I'm trying to set up subversion again. I saved my
private key file, and I can use plink -T to connect and I get:
( success ( 1 2 ( ANONYMOUS EXTERNAL ) ( edit-pipeline ) ) )
and that seems correct, and jiv
On 2/21/06, Robert Brewer <[EMAIL PROTECTED]> wrote:
> 1. Allow trace hooks to receive c_call, c_return, and c_exception events
> (like profile does).
I can easily make this modification. You can also register the same
bound method for trace and profile, which sortof eliminates this
problem.
> 2
On 8/8/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Nicholas Bastin wrote:
> > It's a mature product. I would hope that that would count for
> > something.
>
> Sure. But so is subversion.
I will then assume that you and I have different ideas o
On 8/4/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Nicholas Bastin wrote:
> > Perforce is a commercial product, but it can be had for free for
> > verified Open Source projects, which Python shouldn't have any problem
> > with. There are other prob
On 8/2/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> George V. Neville-Neil wrote:
> > Since Python is Open Source are you looking at Per Force which you can
> > use for free and seems to be a happy medium between something like CVS
> > and something horrific like Clear Case?
>
> No. The PEP
On 7/12/05, Christoph Ludwig <[EMAIL PROTECTED]> wrote:
> If distutils builds C++ extensions with the C compiler then I consider this a
> bug in distutils because it is unlikely to work. (Unless the compiler can
> figure out from the source file suffixes in the compilation step *and* some
> info in
On May 10, 2005, at 7:34 PM, James Y Knight wrote:
> If you're going to call python's implementation UTF-16, I'd consider
> all these very serious deficiencies:
The --enable-unicode option declares a character encoding form (CEF),
not a character encoding scheme (CES). It is unfortunate that U
On May 9, 2005, at 12:59 AM, Martin v. Löwis wrote:
>> Wow, what an inane way of looking at it. I don't know what world you
>> live in, but in my world, users read the configure options and suppose
>> that they mean something. In fact, they *have* to go off on their own
>> to assume something,
On May 8, 2005, at 1:44 PM, Martin v. Löwis wrote:
> Shane Hathaway wrote:
>> Fair enough. The original point is that the documentation is unclear
>> about what a Py_UNICODE[] contains. I deduced that it contains either
>> UCS2 or UCS4 and implemented accordingly. Not only did I guess wrong,
>
On May 8, 2005, at 5:28 AM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> All of my proposals for what to change the documention to have been
>> shot down by Martin. If someone has better verbiage that they'd like
>> to see, I'd be perfectly happy to patch
On May 8, 2005, at 5:15 AM, Martin v. Löwis wrote:
> 'configure takes an option --enable-unicode, with the possible
> values "ucs2", "ucs4", "yes" (equivalent to no argument),
> and "no" (equivalent to --disable-unicode)'
>
> *THIS* documentation would break. This documentation is factually
> co
On May 7, 2005, at 5:09 PM, M.-A. Lemburg wrote:
> Please upload your doc-patch to SF.
All of my proposals for what to change the documention to have been
shot down by Martin. If someone has better verbiage that they'd like
to see, I'd be perfectly happy to patch the doc.
My last suggestion
On May 7, 2005, at 5:09 PM, M.-A. Lemburg wrote:
> However, I don't understand all the excitement
> about Py_UNICODE: if you don't like the way this Python
> typedef works, you are free to interface to Python using
> any of the supported encodings using PyUnicode_Encode()
> and PyUnicode_Decode()
On May 7, 2005, at 9:29 AM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> --enable-unicode=ucs2
>>
>> be replaced with:
>>
>> --enable-unicode=utf16
>>
>> and the docs be updated to reflect more accurately the variance of the
>>
On May 7, 2005, at 9:24 AM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> Yes, but the important question here is why would we want that? Why
>> doesn't Python just have *one* internal representation of a Unicode
>> character? Having more than one possib
On May 6, 2005, at 8:11 PM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> Well, this is a completely separate issue/problem. The internal
>> representation is UTF-16, and should be stated as such. If the
>> built-in methods actually don't work with surrogate pai
On May 6, 2005, at 8:25 PM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> Yes. Not only in my mind, but in the Python source code. If
>> Py_UNICODE is 4 bytes wide, then the encoding is UTF-32 (UCS-4),
>> otherwise the encoding is UTF-16 (*not* UCS-2).
>
>
On May 6, 2005, at 7:45 PM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> Because the encoding of that buffer appears to be different depending
>> on
>> the configure options.
>
> What makes it appear so? sizeof(Py_UNICODE) changes when you change
> the op
On May 6, 2005, at 7:43 PM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> If this is the case, then we're clearly misleading users. If the
>> configure script says UCS-2, then as a user I would assume that
>> surrogate pairs would *not* be encoded, because I chos
On May 6, 2005, at 5:21 PM, Shane Hathaway wrote:
> Nicholas Bastin wrote:
>> On May 6, 2005, at 3:42 PM, James Y Knight wrote:
>>> It means all the string operations treat strings as if they were
>>> UCS-2, but that in actuality, they are UTF-16. Same as the case i
On May 6, 2005, at 3:42 PM, James Y Knight wrote:
> On May 6, 2005, at 2:49 PM, Nicholas Bastin wrote:
>> If this is the case, then we're clearly misleading users. If the
>> configure script says UCS-2, then as a user I would assume that
>> surrogate pairs would *
After reading through the code and the comments in this thread, I
propose the following in the documentation as the definition of
Py_UNICODE:
"This type represents the storage type which is used by Python
internally as the basis for holding Unicode ordinals. Extension module
developers should
On May 6, 2005, at 3:17 AM, M.-A. Lemburg wrote:
> You've got that wrong: Python let's you choose UCS-4 -
> UCS-2 is the default.
No, that's not true. Python lets you choose UCS-4 or UCS-2. What the
default is depends on your platform. If you run raw configure, some
systems will choose UCS-
On May 6, 2005, at 3:25 AM, M.-A. Lemburg wrote:
> I don't see why you shouldn't use Py_UNICODE buffer directly.
> After all, the reason why we have that typedef is to make it
> possible to program against an abstract type - regardless of
> its size on the given platform.
Because the encoding of
On May 6, 2005, at 3:17 AM, M.-A. Lemburg wrote:
> You've got that wrong: Python let's you choose UCS-4 -
> UCS-2 is the default.
>
> Note that Python's Unicode codecs UTF-8 and UTF-16
> are surrogate aware and thus support non-BMP code points
> regardless of the build type: A UCS2-build of Pytho
On May 4, 2005, at 6:20 PM, Shane Hathaway wrote:
> Martin v. Löwis wrote:
>> Nicholas Bastin wrote:
>>
>>> "This type represents the storage type which is used by Python
>>> internally as the basis for holding Unicode ordinals. Extension
>>> m
On May 4, 2005, at 6:03 PM, Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>> "This type represents the storage type which is used by Python
>> internally as the basis for holding Unicode ordinals. Extension
>> module
>> developers should make no assumption
On May 4, 2005, at 1:02 PM, Michael Hudson wrote:
> Nicholas Bastin <[EMAIL PROTECTED]> writes:
>
>> The current documentation for Py_UNICODE states:
>>
>> "This type represents a 16-bit unsigned storage type which is used by
>> Python internally
The current documentation for Py_UNICODE states:
"This type represents a 16-bit unsigned storage type which is used by
Python internally as basis for holding Unicode ordinals. On platforms
where wchar_t is available and also has 16-bits, Py_UNICODE is a
typedef alias for wchar_t to enhance
On May 4, 2005, at 1:39 PM, M.-A. Lemburg wrote:
> Nicholas Bastin wrote:
>> On May 4, 2005, at 4:39 AM, M.-A. Lemburg wrote:
>>>> At the very least, if we can't guarantee the internal
>>>> representation, then the PyUnicode_FromUnicode API needs to go
>
On May 4, 2005, at 4:39 AM, M.-A. Lemburg wrote:
>> At the very least, if we can't guarantee the internal representation,
>> then the PyUnicode_FromUnicode API needs to go away, and be replaced
>> with something capable of transcoding various unicode inputs into the
>> internal python represent
On May 3, 2005, at 6:44 PM, Guido van Rossum wrote:
> I think that documentation is wrong; AFAIK Py_UNICODE has always been
> allowed to be either 16 or 32 bits, and the source code goes through
> great lengths to make sure that you get a link error if you try to
> combine extensions built with d
The documentation for Py_UNICODE states the following:
"This type represents a 16-bit unsigned storage type which is used by
Python internally as basis for holding Unicode ordinals. On platforms
where wchar_t is available and also has 16-bits, Py_UNICODE is a
typedef alias for wchar_t to enha
Why is PyCallable_Check declared in both object.h and abstract.h? It
appears that it's been this way for quite some time (exists in both
2.3.4 and 2.4.1).
--
Nick
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
On Apr 7, 2005, at 11:35 AM, M.-A. Lemburg wrote:
Ok, but I don't really follow you here: you are suggesting to
relax the current UTF-16 behavior and to start defaulting to
UTF-16-BE if no BOM is present - that's most likely going to
cause more problems that it seems to solve: namely complete
garba
On Apr 7, 2005, at 5:07 AM, M.-A. Lemburg wrote:
The current implementation of the utf-16 codecs makes for some
irritating gymnastics to write the BOM into the file before reading it
if it contains no BOM, which seems quite like a bug in the codec.
The codec writes a BOM in the first call to .write
On Apr 5, 2005, at 6:19 AM, M.-A. Lemburg wrote:
Note that the UTF-16 codec is strict w/r to the presence
of the BOM mark: you get a UnicodeError if a stream does
not start with a BOM mark. For the UTF-8-SIG codec, this
should probably be relaxed to not require the BOM.
I've actually been confused
On Mar 10, 2005, at 11:00 AM, Phillip J. Eby wrote:
At 01:38 AM 3/10/05 -0500, Nicholas Bastin wrote:
I realize that this is exceedingly late in the game, but is anybody
interested in doing a Write-Python-Bindings-for-SWT sprint? It's
been brought up before in various places, and PyCon
I realize that this is exceedingly late in the game, but is anybody
interested in doing a Write-Python-Bindings-for-SWT sprint? It's been
brought up before in various places, and PyCon seems the likely place
to get enough concentrated knowledge to actually get it kicked off and
somewhat workin
49 matches
Mail list logo
