On 8/9/2018 8:45 AM, Poornima .D. wrote:
I have limited knowledge on python development. I am trying to write a
test application which needs to import from many packages across
mutliple directories.
I tried using an environment variable and appending to sys.path variable
so that import Cla
Hi Poornima,
Your question is more appropriate for the python-list mailing list (
https://mail.python.org/mailman/listinfo/python-list) or python-tutors
mailing list (https://mail.python.org/mailman/listinfo/tutor).
On Thu, Aug 9, 2018, 8:30 AM Poornima .D. wrote:
> Hi All,
>
>
> I have limit
Hello.
This mailing list is to work on developing Python (adding new
features to Python itself and fixing bugs); if you're having problems
learning, understanding or using Python, please find another forum.
Probably python-list/comp.lang.python mailing list/news group is the
best place; there a
This mailing list is for the discussion of the development *of* Python, not
its use. Your best bet for help is either a site like Stack Overflow or
another mailing list like python-tutor or python-list.
On Thu, 9 Aug 2018 at 08:30 Poornima .D. wrote:
> Hi All,
>
>
> I have limited knowledge on p
General questions like this belong on python-list, not python-dev.
To answer your question, though, you need to run that command from the
Windows Command Prompt, not from the Python interpreter.
___
Python-Dev mailing list
Python-Dev@python.org
https://m
Hello.
We are sorry but we cannot help you. This mailing list is to work on
developing Python (adding new features to Python itself and fixing bugs);
if you're having problems learning, understanding or using Python, please
find another forum. Probably python-list/comp.lang.python mailing list/
You might want to try asking on python-l...@python.org to get a wider
audience as you might find a fellow AIX user there who can help you out.
On Wed Feb 11 2015 at 12:29:56 AM Dwight wrote:
> Hi,
> I am primarily a user; but since I can not get a newer version
> of firefox for my system I
On 11/16/14 8:23 PM, Terry Reedy wrote:
Stefano, the right place to send an enquiry about a bug is python-list,
not py-dev.
ok, sorry, but I wasn't even sure if it was a bug, and what was the root
cause.
I'm doubtful this is a Python problem though. More likely it is an
issue with the cu
On 11/16/2014 11:49 AM, R. David Murray wrote:
On Sun, 16 Nov 2014 11:23:41 +0100, Stefano Borini
wrote:
I report a finding (bug?) about the warning unicode symbol, as reported here
http://stackoverflow.com/questions/26919799/cannot-make-warning-sign-visible-on-osx-terminal
Stefano, the rig
On Sun, 16 Nov 2014 11:23:41 +0100, Stefano Borini
wrote:
> I report a finding (bug?) about the warning unicode symbol, as reported here
>
> http://stackoverflow.com/questions/26919799/cannot-make-warning-sign-visible-on-osx-terminal
Bugs should be reported to bugs.python.org. They just get lo
On 11/1/2014 11:03 PM, Donald Stufft wrote:
On Nov 1, 2014, at 10:37 PM, Terry Reedy wrote:
abort: data/Doc/howto/webservers.rst.i@5f4ad429ae9f: unknown parent!
remote: Unable to write to standard output: The pipe is being closed.
The internet suggests trying hg verify, does that do anyt
> On Nov 1, 2014, at 10:37 PM, Terry Reedy wrote:
>
> My normally dependable pull.bat script has 3 times given me this.
>
> F:\Python\dev>hg --repository F:\Python\dev\5\py35 pull --verbose --config
> ui.merge=internal:merge ssh://h...@hg.python.org/cpython
> pulling from ssh://h...@hg.python.
In article , Georg Brandl
wrote:
> Am 04.11.2013 01:59, schrieb Ned Deily:
> > In article <21110.62791.44734.656...@cochabamba.vanoostrum.org>,
> > Piet van Oostrum wrote:
> >> I tried to install matplotlib 1.3.1 on the release candidates of Python
> >> 2.7.6
> >> and 3.3.3.
> >
> > [...]
>
Oleg Broytman phdru.name> writes:
>
> On Mon, Jun 17, 2013 at 06:37:49PM +, Vinay Sajip
yahoo.co.uk> wrote:
> > echo off
> > __VENV_PYTHON__ -c "import sys, pydoc; sys.exit(pydoc.cli())"
>
>I think you want to pass command line arguments:
>
> echo off
> __VENV_PYTHON__ -c "import
On Mon, Jun 17, 2013 at 06:37:49PM +, Vinay Sajip
wrote:
> @echo off
> __VENV_PYTHON__ -c "import sys, pydoc; sys.exit(pydoc.cli())"
I think you want to pass command line arguments:
@echo off
__VENV_PYTHON__ -c "import sys, pydoc; sys.exit(pydoc.cli())" %1 %2 %3 %4 %5 %6
%7 %8 %9
Oleg.
On Mon, 17 Jun 2013 16:27:45 -, Vinay Sajip wrote:
> Issue #18224 (http://bugs.python.org/issue18224) highlights a problem on
> Windows with the pydoc script provided with venvs created by pyvenv. On
> POSIX, the script is named pydoc and causes no problems: on Windows, it is
> called pydoc.py
Richard Oudkerk gmail.com> writes:
>
> Can't a batch file pydoc.bat be used?
>
I generally find .bat files so limiting that I never thought of that. In
this case, it makes perfect sense to use one. Thanks!
@echo off
__VENV_PYTHON__ -c "import sys, pydoc; sys.exit(pydoc.cli())"
should do it.
On 17/06/2013 5:27pm, Vinay Sajip wrote:
3. Rename the pydoc.py script to pydoc-script.py and introduce a simple .exe
launcher pydoc.exe adjacent to it (which is how setuptools and distlib
handle installed scripts).
Can't a batch file pydoc.bat be used?
--
Richard
Quoting Paul Smith :
My case may be unusual but even in a
more formal cross-compilation environment it's not good to
add /usr/include/..., or base such a decision on the behavior of the
_build_ system.
The offical procedure to cover "unusual" cases is to edit Modules/Setup.
If you are not hap
In article <137129.4119.53.camel@homebase>,
Paul Smith wrote:
> It seems to me (keeping with the theme of this mailing list) that the
> add_multiarch_paths() function in setup.py is not right. [...]
If you think there is a problem, please open an issue for it on the
Python bug tracker: htt
On Fri, 2013-05-31 at 01:21 -0700, Ned Deily wrote:
> In article <1369986770.4119.43.camel@homebase>,
> Paul Smith wrote:
>
> > Hi all. I'm trying to build Python 2.7.5 on a GNU/Linux (Linux Mint 14)
> > system, but using a different sysroot (that is, a separate
> > /usr/include, /usr/lib, etc.
In article <1369986770.4119.43.camel@homebase>,
Paul Smith wrote:
> Hi all. I'm trying to build Python 2.7.5 on a GNU/Linux (Linux Mint 14)
> system, but using a different sysroot (that is, a separate
> /usr/include, /usr/lib, etc., not the real one for my system).
This list is for the develop
Am 30.08.12 22:22, schrieb Manu:
That's right, sorry. The reason why I think this is a double free is
that the op seems to point to an object that has been deallocated by python.
(gdb) select-frame 0
(gdb) print *op
$6 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x2364020}
Does
On Thu, Aug 30, 2012 at 8:49 PM, "Martin v. Löwis" wrote:
> Am 30.08.12 14:39, schrieb Manu:
>
> After spending quite a bit of time trying to understand what could go
>> wrong in the C extensions I use, and not finding anything interesting, I
>> decided to try to find the problem with gdb. The st
Am 30.08.12 14:39, schrieb Manu:
After spending quite a bit of time trying to understand what could go
wrong in the C extensions I use, and not finding anything interesting, I
decided to try to find the problem with gdb. The stacktrace I have seems
to mean that we are trying to double free someth
Hello,
On Thu, 30 Aug 2012 14:39:41 +0200
Manu wrote:
> Hi,
>
> I am currently hitting http://bugs.python.org/issue13992.
>
> I have a scenario that reproduces the bug after 1 to 2 hours (intensive
> sqlalchemy and threading). I get the same stack trace as described in the
> bug.
>
[...]
>
>
2012/7/6 Ned Deily :
> pushing to ssh://pyhg/devguide
> searching for changes
> remote: adding changesets
> remote: adding manifests
> remote: adding file changes
> remote: added 1 changesets with 1 changes to 1 files
> remote: sent email to roundup at rep...@bugs.python.org
> remote: notified pyth
2012/3/8 Antoine Pitrou :
> On Thu, 8 Mar 2012 14:36:06 -0600
> Benjamin Peterson wrote:
>> 2012/3/8 Stefan Behnel :
>> > Would that be acceptable for CPython as well or would you prefer full
>> > fledged normalisation?
>>
>> I think we have to normalize for correctness. Consider that it may be
>>
On Thu, 8 Mar 2012 14:36:06 -0600
Benjamin Peterson wrote:
> 2012/3/8 Stefan Behnel :
> > Would that be acceptable for CPython as well or would you prefer full
> > fledged normalisation?
>
> I think we have to normalize for correctness. Consider that it may be
> some StopIteration subclass which
2012/3/8 Stefan Behnel :
> Would that be acceptable for CPython as well or would you prefer full
> fledged normalisation?
I think we have to normalize for correctness. Consider that it may be
some StopIteration subclass which set "value" on construction.
--
Regards,
Benjamin
___
Stefan Behnel, 07.03.2012 21:40:
> I found a problem in the current "yield from" implementation
... and here's another one, also in genobject.c:
"""
int
PyGen_FetchStopIterationValue(PyObject **pvalue) {
PyObject *et, *ev, *tb;
PyObject *value = NULL;
if (PyErr_ExceptionMatches(PyExc
On Thu, Mar 8, 2012 at 11:45 PM, Mark Shannon wrote:
> It really ought say that "yield from" is equivalent to inlining
> in the PEP.
That's what the motivation section is about. There's also an entire
subsection called "The Refactoring Principle" that describes this
intent. However, we needed som
Nick Coghlan wrote:
On Thu, Mar 8, 2012 at 9:52 PM, Mark Shannon wrote:
First of all, the semantics described in the PEP do not match the tests.
If you substitute the supposedly semantically equivalent code
based on normal yields for each yield from in the test code
(Lib/test/test_pep380.py) an
On Thu, Mar 8, 2012 at 9:52 PM, Mark Shannon wrote:
> First of all, the semantics described in the PEP do not match the tests.
> If you substitute the supposedly semantically equivalent code
> based on normal yields for each yield from in the test code
> (Lib/test/test_pep380.py) and run it, then
On Thu, Mar 8, 2012 at 9:52 PM, Mark Shannon wrote:
> I would recommend changing one of two things in the PEP:
> Either, close and throw should not close/throw in subiterators
> (this would simplify the semantics and implementation immensely)
> Or, only allow subgenerators, not subiterators
> (thi
Stefan Behnel wrote:
Hi,
I found a problem in the current "yield from" implementation that I think
is worth discussing:
http://bugs.python.org/issue14220
[snip]
I've been experimenting with the implementation of PEP 380, and I found
a couple of interesting things.
First of all, the semant
On Thu, Mar 8, 2012 at 10:32 AM, Jim J. Jewett wrote:
> How is this a problem?
>
> Re-entering a generator is a bug. Python caught it and raised an
> appropriate exception.
No, the problem was that the interpreter screwed up the state of the
generators while attempting to deal with the erroneous
On Thu, Mar 8, 2012 at 10:00 AM, Benjamin Peterson wrote:
> 2012/3/7 Benjamin Peterson :
>> 2012/3/7 Stefan Behnel :
>>> The problem is in steps 5) and 6), which are handled by g1 at the wrong
>>> call level. They shouldn't lead to undelegation and termination in g1, just
>>> to an exception being
2012/3/7 Benjamin Peterson :
> 2012/3/7 Stefan Behnel :
>> The problem is in steps 5) and 6), which are handled by g1 at the wrong
>> call level. They shouldn't lead to undelegation and termination in g1, just
>> to an exception being raised in g2.
>
> That looks wrong indeed.
Fixed as of 3357eac1
On Thu, Mar 8, 2012 at 6:40 AM, Stefan Behnel wrote:
> I ran into this while trying to adapt the implementation for Cython, which
> has a different generator type implementation but otherwise uses more or
> less the same code now. But I'm not sure how to fix this one without major
> changes to the
2012/3/7 Stefan Behnel :
> The problem is in steps 5) and 6), which are handled by g1 at the wrong
> call level. They shouldn't lead to undelegation and termination in g1, just
> to an exception being raised in g2.
That looks wrong indeed.
>
> I ran into this while trying to adapt the implementat
Hello Vahid,
i'm sorry but this mailing list is not the right place where to ask
such question, I suggest get in touch with
http://mail.python.org/mailman/listinfo/python-list for support.
On Sat, Feb 18, 2012 at 18:15, Vahid Ghaderi wrote:
> i have downloaded and installed python 3.2.2 but still
This list is for the development of Python, not questions about its
use. You should ask python-list. None the less, it's because input()
changed between Python 2 and 3. Look at the docs for both.
2010/9/15 João Vitor :
> I made a program that, according to my teacher, is correct but is not
> runni
Hello.
We'are sorry but we cannot help you. This mailing list is to work on
developing Python (fixing bugs and adding new features to Python itself); if
you're having problems using Python, please find another forum. Probably
python-list (comp.lang.python) news group/mailing list is the best pl
> live with, but I wonder why is it necessary for python.org to be
> registered as both an IPv4 and v6 domain? Google does not do that:
Google works in changing that:
http://www3.ietf.org/proceedings/08jul/slides/plenaryw-4.pdf
Other systems have been doing it for many years now:
mar...@mira:~
On Sun, Dec 14, 2008 at 5:18 PM, "Martin v. Löwis" wrote:
>> I've found a work-around in Firefox: go to about:config page an change
>> network.dns.disableIPv6 to true.
>
> I'd advise against using such a work-around. The infrastructure is
> designed to cope with that case transparently; if it is n
> I've found a work-around in Firefox: go to about:config page an change
> network.dns.disableIPv6 to true.
I'd advise against using such a work-around. The infrastructure is
designed to cope with that case transparently; if it is not transparent,
your system must be somehow misconfigured (it coul
I've found a work-around in Firefox: go to about:config page an change
network.dns.disableIPv6 to true.
Does anyone know a similar setting in Safari?
On Sun, Dec 14, 2008 at 4:52 PM, Alexander Belopolsky
wrote:
> Please see below for more svn debugging, but now I also traced down
> the delays I
Please see below for more svn debugging, but now I also traced down
the delays I observe when I go to bugs.python.com to the same issue.
The offending download is the style sheet and that explains why curl
does not show it when pointed to the main page:
$ curl -v -o /dev/null http://python.org/sty
> I don't know is this is related
It shouldn't. AFAIK, buildbot makes its internet connections
through twisted, and twisted doesn't use IPv6. Also, the diagnostics
(cannot resolve name) doesn't match connectivity problems.
> $ time curl -v -o /dev/null http://svn.python.org
> * About to connect()
Alexander> It looks like it has something to do with IPv6:
Alexander> $ host svn.python.org svn.python.org has address
Alexander> 82.94.164.164 svn.python.org has IPv6 address
Alexander> 2001:888:2000:d::a4
...
Alexander> No slowdown when IPv6 lookup is disabled with -4 op
I don't know is this is related, but from my end, access to
svn.python.org has been extremely slow recently:
$ time curl -o /dev/null http://svn.python.org
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total Spent
Martin> Well - can you resolve `svn.python.org' on that machine
Martin> (e.g. when using ping(1))?
Yup:
$ host svn.python.org
svn.python.org has address 82.94.164.164
svn.python.org has IPv6 address 2001:888:2000:d::a4
$ ping svn.python.org
PING svn.python.org (82.94.
> svn: PROPFIND of '/projects/python/branches/release25-maint': Could not
> resolve hostname `svn.python.org': Temporary failure in name resolution
> (http://svn.python.org)
>
> Any idea what the problem might be?
Well - can you resolve `svn.python.org' on that machine (e.g. when
using ping
Greg Ewing schrieb:
> Correct me if I'm wrong, but what I got from the OP
> was that the current method does
Ok, I'm correcting you: This is not what the current
method does:
>
>if (is_tripped) {
> for each signal {
>if the signal has occurred, call its handler
> }
> i
On 1/27/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Why not?
>
> Correct me if I'm wrong, but what I got from the OP
> was that the current method does
>
>if (is_tripped) {
> for each signal {
>if the signal has occurred, call its handler
> }
> is_tripped = 0;
>}
>
Martin v. Löwis wrote:
> Greg Ewing schrieb:
>
>>>Please
>>>try to come up with a patch (e.g. by putting a while(is_tripped) loop
>>>around the for loop).
>>
>>That isn't going to fix it.
>
> Why not?
Correct me if I'm wrong, but what I got from the OP
was that the current method does
if (i
I apologise for going off-topic, but this is an explanation of why
I said that signal handling is not reliable. The only relevance to
Python is that Python should avoid relying on signals if possible,
and try to be a little defensive if not. Signals will USUALLY do
what is expected, but not alway
Greg Ewing schrieb:
>> Please
>> try to come up with a patch (e.g. by putting a while(is_tripped) loop
>> around the for loop).
>
> That isn't going to fix it.
Why not?
> What's needed is to somehow
> atomically test and clear is_tripped at the beginning.
How would that help? The case in quest
Nick Maclaren wrote:
> This one looks like an oversight in Python code, and so is a bug,
> but it is important to note that signals do NOT work reliably under
> any Unix or Microsoft system.
That's a rather pessimistic way of putting it. In my
experience, signals in Unix mostly do what they're
me
Martin v. Löwis wrote:
> Please
> try to come up with a patch (e.g. by putting a while(is_tripped) loop
> around the for loop).
That isn't going to fix it. What's needed is to somehow
atomically test and clear is_tripped at the beginning.
You can put a while loop around it as well if you want,
bu
On 1/24/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Gustavo Carneiro schrieb:
>What about http://www.python.org/sf/1564547 ? It tries to solve a
> different problem, but I think it also fixes this one; at least as much
> as possible with the braindead unix signal programming interface.
On 1/24/07, Ulisses Furquim <[EMAIL PROTECTED]> wrote:
> On 1/24/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I agree it's a bug, and I agree with your proposed analysis. Please
> > try to come up with a patch (e.g. by putting a while(is_tripped) loop
> > around the for loop). Also make sur
Gustavo Carneiro schrieb:
>What about http://www.python.org/sf/1564547 ? It tries to solve a
> different problem, but I think it also fixes this one; at least as much
> as possible with the braindead unix signal programming interface...
I'm sceptical. It is way too much code for me to review,
On 1/24/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Ulisses Furquim schrieb:
> I've read some threads about signals in the archives and I was under
> the impression signals should work reliably on single-threaded
> applications. Am I right? I've thought about a way to fix this, but I
> don
On 1/24/07, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> Obviously, Unix and Microsoft systems depend on signals, so you
> can't simply regard them as hopelessly broken, but you can't assume
> that they are RELIABLE. All code should be designed to cope with
> the case of signals getting lost, if at
On 1/24/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I agree it's a bug, and I agree with your proposed analysis. Please
> try to come up with a patch (e.g. by putting a while(is_tripped) loop
> around the for loop). Also make sure you include test case.
Ok. I was discussing this problem wit
On Tue, Jan 23, 2007, Ulisses Furquim wrote:
>
> I've read some threads about signals in the archives and I was under
> the impression signals should work reliably on single-threaded
> applications. Am I right? I've thought about a way to fix this, but I
> don't know what is the current plan for s
Ulisses Furquim schrieb:
> I've read some threads about signals in the archives and I was under
> the impression signals should work reliably on single-threaded
> applications. Am I right? I've thought about a way to fix this, but I
> don't know what is the current plan for signals support in pyth
On Tue, Jan 23, 2007, Ulisses Furquim wrote:
>
> I've read some threads about signals in the archives and I was under
> the impression signals should work reliably on single-threaded
> applications. Am I right? I've thought about a way to fix this, but I
> don't know what is the current plan for s
On 1/20/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2007-01-20 00:01, Brett Cannon wrote:
> > On 1/19/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> >> On 2007-01-19 22:33, Brett Cannon wrote:
> That's a typical error situation you get in __del__ methods at
> the time the interprete
On 2007-01-20 00:01, Brett Cannon wrote:
> On 1/19/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2007-01-19 22:33, Brett Cannon wrote:
That's a typical error situation you get in __del__ methods at
the time the interpreter is shut down.
>>> Yeah, but in this case this is at the
Josiah Carlson schrieb:
> I was saying that it would be nice if the following were true:
>
> >>> encodings.__module__
>
Ah, ok. It would be somewhat confusing, though, that __module__ is
sometimes a module object, and sometimes a string (it certainly confused
me).
> So what if it is a c
On 1/19/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2007-01-19 22:33, Brett Cannon wrote:
> >> That's a typical error situation you get in __del__ methods at
> >> the time the interpreter is shut down.
> >>
> >
> > Yeah, but in this case this is at the end of Py_Initialize() for the
> > stuff
On 2007-01-19 22:33, Brett Cannon wrote:
>> That's a typical error situation you get in __del__ methods at
>> the time the interpreter is shut down.
>>
>
> Yeah, but in this case this is at the end of Py_Initialize() for the
> stuff I am doing to the interpreter. =)
Is that in some error branch
On 1/18/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Brett Cannon schrieb:
> > Anybody have any ideas on how to deal with this short of rewriting
> > some codecs stuff so that they don't depend on global state in the
> > module or just telling me to just live with it?
>
> There is an old patc
On 1/19/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2007-01-18 20:53, Brett Cannon wrote:
> > I have discovered an issue relating to func_globals for functions and
> > the deallocation of the module it is contained within. Let's say you
> > store a reference to the function encodings.search_
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson schrieb:
> > Seems to me like a bug, but the bug could be fixed if the module's
> > dictionary kept a (circular) reference to the module object. Who else
> > has been waiting for a __module__ attribute?
>
> This is the time machine
On 2007-01-18 20:53, Brett Cannon wrote:
> I have discovered an issue relating to func_globals for functions and
> the deallocation of the module it is contained within. Let's say you
> store a reference to the function encodings.search_function from the
> 'encodings' module (this came up in C cod
Josiah Carlson schrieb:
> Seems to me like a bug, but the bug could be fixed if the module's
> dictionary kept a (circular) reference to the module object. Who else
> has been waiting for a __module__ attribute?
This is the time machine at work:
py> import encodings
py> encodings.search_function
Brett Cannon schrieb:
> Anybody have any ideas on how to deal with this short of rewriting
> some codecs stuff so that they don't depend on global state in the
> module or just telling me to just live with it?
There is an old patch by Armin Rigo ( python.org/sf/812369 ), which
attempts to implemen
"Brett Cannon" <[EMAIL PROTECTED]> wrote:
> I have discovered an issue relating to func_globals for functions and
> the deallocation of the module it is contained within. Let's say you
> store a reference to the function encodings.search_function from the
> 'encodings' module (this came up in C c
>>
>> Use an absolute path to the library rather than -framework.
>
> That is, add '/Library/Frameworks/Python.framework/Versions/2.4/
> Python' to the link command instead of '-framework Python'.
Thanks I'll update my builds to do that.
>>
>> Or use distutils!
>
> That's definitely advisable a
On Oct 15, 2006, at 9:41 PM, Bob Ippolito wrote:
On 10/15/06, Barry Scott <[EMAIL PROTECTED]> wrote:
This may be down to my lack of knowledge of Mac OS X development.
I want to build my python extension for Python 2.3, 2.4 and 2.5 on
the same Mac.
Build Python 2.3 and Python 2.4 has been work
On 10/15/06, Barry Scott <[EMAIL PROTECTED]> wrote:
> This may be down to my lack of knowledge of Mac OS X development.
>
> I want to build my python extension for Python 2.3, 2.4 and 2.5 on
> the same Mac.
> Build Python 2.3 and Python 2.4 has been working well for a long
> time. But
> after I ins
+1
On 9/1/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Currently, both the partition() and rpartition() methods return a (head,
> sep, tail) tuple and the only difference between the two is whether the
> partition element search starts from the beginning or end of the
> string. When no sepa
On 7/18/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> I think this was Greg's point. Talking about C++ and super() is
> nonsensical.
If you're talking pure C++, yes. But I was talking about programming
system built on top of C++ implementing cooperating multitasking.
As I am fond of repea
On 7/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > In the world where cooperative multiple inheritance
> > originated (C++), this would be a static error.
>
> I wasn't aware that C++ had anything resembling super().
> Is it a recent addition to the language?
I don't kn
On 7/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> C++ originally specified multiple inheritance, but it wasn't "cooperative" in
> the sense that super is. In Lisp, though, where cooperative method dispatch
> originated, call-next-method does basically the same thing in the case where
> th
On Tue, 18 Jul 2006 09:24:57 -0400, Jean-Paul Calderone <[EMAIL PROTECTED]>
wrote:
>On Tue, 18 Jul 2006 09:10:11 -0400, Scott Dial <[EMAIL PROTECTED]> wrote:
>>Greg Ewing wrote:
>>> Guido van Rossum wrote:
In the world where cooperative multiple inheritance
originated (C++), this would
On Tue, 18 Jul 2006 09:10:11 -0400, Scott Dial <[EMAIL PROTECTED]> wrote:
>Greg Ewing wrote:
>> Guido van Rossum wrote:
>>> In the world where cooperative multiple inheritance
>>> originated (C++), this would be a static error.
>>
>> I wasn't aware that C++ had anything resembling super().
>> Is it
Greg Ewing wrote:
> Guido van Rossum wrote:
>> In the world where cooperative multiple inheritance
>> originated (C++), this would be a static error.
>
> I wasn't aware that C++ had anything resembling super().
> Is it a recent addition to the language?
>
It is much more explicit, but you call t
Guido van Rossum wrote:
> In the world where cooperative multiple inheritance
> originated (C++), this would be a static error.
I wasn't aware that C++ had anything resembling super().
Is it a recent addition to the language?
--
Greg
___
Python-Dev mail
On 7/16/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> For about the third time in my life, I thought I might
> have found a use for cooperative super calls, but I've
> run into another problem with the concept.
>
> Consider:
>
> class A(object):
>def m(self):
> print "A.m"
>
> class B(ob
At 12:13 PM 4/30/2006 +0200, Georg Brandl wrote:
>Recently, the inspect module was updated to conform with PEP 302.
>
>Now this is broken:
>
> >>> import inspect
> >>> inspect.stack()
>
>The traceback shows clearly what's going on. However, I don't know how
>to resolve the problem.
The problem as
Anthony Baxter wrote:
> There's a scripts Tools/scripts/reindent.py - put it somewhere on your
> PATH and run it before checkin, like "reindent.py -r Lib". It means Tim
> or I don't have to run it for you
As I kept forgetting what the name, location, and command line options
of that script are, I
Neal Becker wrote:
> x86_64 is multiarch. That means, we allow both i386 and x86_64 binaries to
> coexits. Is the proposal that python should not support this? That would
> be unfortunate.
No. You should install the Python library to the architecture-specific
directory (/usr/lib64/python2.3 for
On Mar 17, 2006, at 4:38 PM, Neal Becker wrote:
> "Martin v. Löwis" wrote:
>
>> Neal Becker wrote:
>>> Sorry, maybe I used confusing terminology.
>>>
>>> A reference is here: http://fedoraproject.org/wiki/Packaging/Python
>>> This is the current setup. For example, this is a standard macro
>>>
On 3/18/06, Neal Becker <[EMAIL PROTECTED]> wrote:
x86_64 is multiarch. That means, we allow both i386 and x86_64 binaries tocoexits. Is the proposal that python should not support this? That wouldbe unfortunate.Not within a single interpreter, I'd say. Extensions compiled for x86_64 will not lo
"Martin v. Löwis" wrote:
> Neal Becker wrote:
>> Sorry, maybe I used confusing terminology.
>>
>> A reference is here: http://fedoraproject.org/wiki/Packaging/Python
>> This is the current setup. For example, this is a standard macro used by
>> Redhat in RPM SPEC files for python:
>>
>> %define
1 - 100 of 121 matches
Mail list logo
