`) and `for sys.prefix` and
>> + `sys.exec_prefix` to be empty. It is up to the caller to modify these if
>> + required after calling :cfunc: `Py_Initialize`.
>> +
>
> This needs a versionadded.
>
> Georg
>
Did you noticed " ... The path components should be s
convert to the Windows religion.
>>
> You mean people using Windows are forced to use Windows?
>
I would say people that want to support Windows but are not using it.
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Pre
On Thu, Nov 12, 2009 at 5:46 PM, "Martin v. Löwis" wrote:
>> (more seriously, the problem with a comment system is that once it takes off,
>> you need a whole array of functionalities to maintain a good S/N ratio. Just
>> allowing people to "comment" without any sort of moderation, filtering or
>>
On Thu, Nov 12, 2009 at 12:32 PM, Jesse Noller wrote:
> On Thu, Nov 12, 2009 at 9:25 AM, Barry Warsaw wrote:
>> On Nov 12, 2009, at 8:06 AM, Jesse Noller wrote:
>>
>>> Frankly, I agree with him. As implemented, I *and others* think this
>>> is broken. I've taken the stance of not publishing thing
I'm getting this warning. It seems nothing is actually broken, but the
fix is pretty easy.
gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-IInclude -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o
Objects/unicodeobject.c
Objects/unicodeobject.c: In function 'PyUnico
On Thu, Jul 23, 2009 at 5:42 PM, Terry Reedy wrote:
> Lisandro Dalcin wrote:
>>
>> On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone
>> wrote:
>>
>>> True, CPython has C infrastructure. What about the other Python
>>> runtimes,
>>> thoug
On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone wrote:
>
> True, CPython has C infrastructure. What about the other Python runtimes,
> though?
>
Perhaps these other Python runtimes could implement the functionality
of PC/_subprocess.c and use ctypes for that ?
--
Lisandro Dalcín
---
On Wed, Jul 22, 2009 at 12:33 PM, Amaury Forgeot
d'Arc wrote:
>
> These questions should be redirected to comp.lang.python.
>
Eric seems to be working on a GSoC for PFS related to improving
subprocess. Even in such case this list is not the right place to make
these posts??
--
Lisandro Dalcín
On Thu, May 18, 2006 at 3:02 PM, "Martin v. Löwis" wrote:
>
> Right. With some googling, I found that one solution is pthread_atexit:
> a pthread_atexit handler is a triple (before, in_parent, in_child).
> You set it to (acquire, release, release).
Did you mean pthread_atfork() ?
> When somebody
Sorry...
-- Forwarded message --
From: Lisandro Dalcin
Date: Tue, Jul 7, 2009 at 7:16 PM
Subject: Re: [Python-Dev] Suggested PySys_SetArgv use with a (char **) argv ?
To: "Martin v. Löwis"
On Tue, Jul 7, 2009 at 6:46 PM, "Martin v. Löwis" wrote:
>>
http://bugs.python.org/issue6195 (with patch)
On Wed, Jun 3, 2009 at 8:26 AM, Amaury Forgeot d'Arc wrote:
> Hello,
>
> 2009/6/3 Stefan Behnel :
>> Hi,
>>
>> I can't currently file a bug report on this, but I was told by Lisandro
>> Dalcín that there is a serious problem with the doctest module in
Martin, a small request.
Any chance you consider defining PyType_Slot like below?
typedef struct{
int slot;/* slot id, see below */
void *pdata; /* data pointer */
void (*pfunc)(void); /* function pointer */
} PyType_Slot
Or perhaps other way? Just to avoid compilers complaining about
On Wed, Apr 15, 2009 at 12:05 AM, Dan Eloff wrote:
>>No, the read() method did not change from the 2.x series. It returns a new
>>object on each call.
>
> I think you misunderstand me, but the readinto() method looks like a
> perfectly reasonable solution, I didn't realize it existed, as it's
> n
Did you read the post until the end? The OP is asking a question
related to a very low level detail of dict implementation and making
an offer to write a patch that could speed-up dict.setdefault() in
core CPython... IMHO, a poll on python-dev do makes sense...
On Tue, Apr 7, 2009 at 1:34 PM, Aahz
On Wed, Apr 1, 2009 at 11:58 PM, Larry Hastings wrote:
>
> Guido van Rossum wrote:
>>
>> Yeah, any two CAPI objects can be used to play this trick, as long as
>> you have some place that calls them. :-(
>
> FWIW, I can't take credit for this observation. Neal Norwitz threw me at
> this class of p
Martin, I was not clear enough. Please, just tell me: Do you believe
that this addition do make sense? Would you reject it for some reason
(other than a bad patch) ?
On Fri, Feb 13, 2009 at 10:35 PM, "Martin v. Löwis" wrote:
>> Mark, the patch is not trivial, I cannot spend time on this until thi
Done, http://bugs.python.org/issue5248
Mark, the patch is not trivial, I cannot spend time on this until this
is accepted. Hope you understand.
On Fri, Feb 13, 2009 at 1:15 PM, Mark Dickinson wrote:
> On Thu, Feb 12, 2009 at 8:42 PM, Lisandro Dalcin wrote:
>> I would like to pr
After a rather long hacking on Cython in order to support 'Py_ssize_t'
and 'size_t' the right way, I would like to propose the inclusion of a
new T_SIZET in structmember.h in order to suport 'size_t' struct
fields with PyMemberDef. Would such addition be accepted for 2.7 and
3.1?
--
Lisandro Da
Done, http://bugs.python.org/issue5175
On Fri, Feb 6, 2009 at 6:25 PM, Mark Dickinson wrote:
> On Fri, Feb 6, 2009 at 9:04 PM, Lisandro Dalcin wrote:
>> At Objects/longobject.c, you should see that in almost all cases
>> OverflowError is raised when a unsigned integral is r
While hacking on Cython to make it recognize 'size_t' as a pre-defined
C integral type, I've found somethig that seems to be (pretty small)
inconsistency.
At Objects/longobject.c, you should see that in almost all cases
OverflowError is raised when a unsigned integral is requested from a
negative
Unless this is considered a regression...
On Tue, Nov 18, 2008 at 12:51 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I think it crosses the line.
>
> On Tue, Nov 18, 2008 at 2:55 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> I need a release manager call on whether or not the proposed resolu
On Thu, Oct 9, 2008 at 8:50 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Christian Heimes]
>>
>> The idea sounds great!
>>
>> Are you planing to embed the pure python code in C code?
>
> Am experimenting with a descriptor that fetches the attribute string from a
> separate text file.
Have y
On 6/5/08, Thomas Heller <[EMAIL PROTECTED]> wrote:
Thomas, Iff this helps, you have attached the backport but as an
extension module. Sorry, I do not have time for the full backport.
But at least, I've found that the Py3K implementation works
You will need to build it with 'python2.6 setup.py bu
Are you completelly sure of adding those guys: PyBytes_InternXXX ???
On 6/1/08, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> > On 2008-05-30 00:57, Nick Coghlan wrote:
> >>
> >> M.-A. Lemburg wrote:
> >>>
> >>> * W
On 5/31/08, Mark Hammond <[EMAIL PROTECTED]> wrote:
> So it seems that maybe simply "setExecutable()" isn't the correct
> abstraction here, but maybe a "factory" approach, so the entire process
> creation mechanism can be replaced rather than just the name of the
> executable to spawn?
Indeed.
On 2/16/08, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> * New float methods: is_finite, is_inf, is_integer and is_nan.
Just a question... is_integer or is_integral?
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo T
On 2/11/08, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> My perception is that you are seeing too much of a connection between
> the C-compiler and the PEP description of memory. Perhaps that's not
> it, and I'm missing something else.
>
Travis, all this make me believe that (perhaps) the 'forma
Currently, PyTuple_Pack() does not check for NULL arguments, so it is
going to segfault in this case. Is this intended for performance
reasons?
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Ind
Yes, you are completely right. I ended up realizing that a change like
this would break almost all third-party extension.
But... What about of doing this for Py3K? Third-party extension have
to be fixed anyway.
On 10/1/07, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Martin,
>
> On Fri, Sep 28, 20
I'm trying to build Python (2.6) with GCC the option -Wwrite-strings.
1 - Is there any interest on this?
2 - What should I do for the very common (taken from int_new):
static char *kwlist[] = {"x", "base", 0};
I was able to remove all the warning in Objects/*, except those related to (2).
-
On 8/2/07, Stargaming <[EMAIL PROTECTED]> wrote:
> >> made into an O(1) operation. here's a demo code (it should be trivial
> >> to implement this in CPython)
> [snipped algorithm]
Did you taked into account that your patch is not backward compatible
with py2.5?? Just try to do this with your patc
Martin, could you please verify if this change did not break the
download counter?
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Ci
On 7/31/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> The Python Packaging Index (the software formerly known
> as Cheeseshop) is now available at
>
> http://pypi.python.org/pypi
Please, update 'DEFAULT_REPOSITORY' in Lib/distutils/command/upload.py
(py-2.6 and py3k-struni branches)
--
Lis
Porting to Py3K, I modified a function like the followin, using a
trick for it working in Py2.x .
def __iter__(self):
if self == _mpi.INFO_NULL:
return
try:range = xrange
except: pass
nkeys = _mpi.info_get_nkeys(self)
for nthkey in range(
Afther checking out the py3k-struni branch, 'make install' issued this:
Compiling /usr/local/python/3.0/lib/python3.0/test/test_tarfile.py ...
*** SyntaxError: ('expected string, bytes found',
('/usr/local/python/3.0/lib/python3.0/test/test_tarfile.py', 0, 0,
None))
If this is expected to fail, p
I did a fresh checkout as below (is p3yk the right branch?)
$ svn co http://svn.python.org/projects/python/branches/p3yk python-3k
after building and installing, I get
$ python3.0
Python 3.0x (p3yk:56529, Jul 24 2007, 15:58:59)
[GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2
Type "help", "copy
I'm porting some of my code to py3k, and I started from the C size.
After this, all extensions compiled fine, but after a 'setup.py
install', I got the following:
File "/usr/local/python/3.0/lib/python3.0/distutils/util.py", line
498, in byte_compile
compile(file, cfile, dfile)
File "/usr/
On 4/13/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> >> int PyObject_GetContiguous(PyObject *obj, void **buf, Py_ssize_t
> >> *len,
> >>int fortran)
> >>
> >> Return a contiguous chunk of memory representing the buffer. If a
> >> copy is made then return 1.
On 4/9/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
Travis, all this is far better and simpler than previous approaches...
Just a few comments
> The bufferinfo structure is::
>
> struct bufferinfo {
>void *buf;
>Py_ssize_t len;
>int readonly;
>char *format;
>
On 7/18/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Raymond Hettinger]
> > ...
> > If the current approach gets in their way, the C implementers should feel
> > free to
> > make an alternate design choice.
>
> I expect they will, eventually. Converting this to C is a big job,
> and at the NFS sp
On 10/19/05, Martin Blais <[EMAIL PROTECTED]> wrote:
> Just wondering, would anyone think of it as a good idea if the
> enumerate() builtin could accept a "start" argument?
And why not an additional "step" argument? Anyway, perhaps all this
can be done with a 'xrange' object...
--
Lisandro Dalcí
On 9/30/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Guido van Rossum]
> > __len__ is for sequences and mappings specifically -- everything that
> > supports __getitem__ should have __len__ and everything that has
> > __len__ should have __getitem__.
>
> That's going a bit far. Unordered co
Jason, this mailing list is related to Python development. If you are
a new at Python, a far better place for help is comp.lang.python
group. Please go to Google Grups and take a look. If you do a search
in those archives, you will find many good links.
--
Lisandro Dalcín
---
Centro
On 9/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> For the builtins, it would actually be possible to do this by simply
> importing an alternate builtins module. Something like
>
> from future_builtins import min, max, zip, range
>
Yes. A straightforward solution...
> For methods on
On 9/9/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> I think it would
> provide a REALLY nice migration path if it were possible to write
> Python 3.0 code in Python 2.x (for large values of x) so long as you
> included an appropriate preamble of "from __future__ import" statements.
Perhaps I
On 9/9/05, holger krekel <[EMAIL PROTECTED]> wrote:
> >
> > It matters because "metaclass = type" is completely obscure. How would
> > any non-expert have a clue what it means?
>
> How would this non-expert have a clue what
> "from __future__ import new_style_classes" means?
>
That is the point!
PEP 3000 says
(http://www.python.org/peps/pep-3000.html) :
Core language
- Return iterators instead of lists where appropriate for atomic type
methods (e.g. dict.keys(), dict.values(), dict.items(), etc.)
Built-in Namespace
- Make built-ins return an iterator where appropriate (e.g. range(),
zip(
On 9/8/05, Aahz <[EMAIL PROTECTED]> wrote:
>
> You can already do
>
> __metaclass__ = type
>
> within each module
>
Yes, you are right. But this way, you are making explicit a behavior
that will be implicit in the future.
For example, we could also do:
two = float(4)/float(2)
instead of
PEP 3000 - Core language says
(http://www.python.org/peps/pep-3000.html#core-language) :
- Support only new-style classes; classic classes will be gone
Any possibility to add something like
from __future__ import new_style_classes
to have newly defined classes implicitly derive from 'object' (I
49 matches
Mail list logo
