On Sun, Jan 25, 2009 at 10:45 AM, Luke Kenneth Casson Leighton
wrote:
>
> from http://en.wikipedia.org/wiki/Dynamic-link_library:
>
> "Third, dynamic linking is inherently the wrong model for paged memory
> managed systems. Such systems work best with the idea that code is
> invariant from the tim
Michael Foord writes:
> > If I can't choose a clear winner I am going to look into what it take
> > to run directly on top of svn to avoid the extra step for committers.
> Well, that sounds like an ideal situation to end up in. Is there a
> downside other than the work it creates for you?
I
"Martin v. Löwis" writes:
> So a conversion to a DVCS would only benefit those committers who
> see a benefit in using a DVCS (*) (and would put a burden on those
> committers who see a DVCS as a burden).
That's false. Especially with bzr, they would see improved log
formats by default, and w
Regardless of the outcome, those that want to use SVN can use SVN, and
those that want to use "chosen DVCS" can use that. In the end, which
is the more "lossy" repository? It seems like if the change is
transparent to everyone who is using it, then the only thing that we
care about is that
Luke Kenneth Casson Leighton wrote:
> i'm sorry to hear that you believe my messages to be sometimes
> offensive. i'm sorry that you are annoyed. i'm sorry that i am
> learning about things and that i believe that people would like to
> help cooperate on the development of python as a free softw
On 2009/01/25, at 3:22 pm, Nick Coghlan wrote:
It needs to go on the tracker regardless of whether the problem is in
the documentation or in the implementation, so file away.
Issue #5062: http://bugs.python.org/issue5062
-- Carl Johnson
___
Python-D
Carl Johnson wrote:
> As I see it, there are two ways to fix the problem: Change the
> documentation or change rlcompleter.Complete. I think the latter option
> is preferable (although it might have to wait for Python 2.7/3.1), but I
> thought I would ask other people if I'm missing something and i
The documentation at http://docs.python.org/library/rlcompleter.html
claims that
Completer.complete(text, state)¶
Return the state*th completion for *text.
If called for text that doesn’t include a period character
('.'), it will complete from names currently defined in __main__,
Since 3.0.1 is going to do a couple of these already, I think that's fine.
On Sun, Jan 25, 2009 at 3:50 PM, Raymond Hettinger wrote:
> For Py3.0.1, can we just rip these out and skip deprecation?
> I don't think they will be missed at all.
>
> Raymond
>
> - Original Message - From: "Guido
For Py3.0.1, can we just rip these out and skip deprecation?
I don't think they will be missed at all.
Raymond
- Original Message -
From: "Guido van Rossum"
To: "Nick Coghlan"
Cc:
Sent: Sunday, January 25, 2009 2:50 PM
Subject: Re: [Python-Dev] Operator module deprecations
+1 ind
> I hope this saves someone else a bit of time. :)
Please submit the parts that you consider of general use
to the bug tracker, so we can include it in future releases.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
Patrick Toal schrieb:
> Hello,
>
> I'm not subscribed to this list, but this is the best place I could
> think of to send this. Please feel free to ignore if this has already
> been addressed, or if I've approached it completely wrong.
>
> When trying to perform an rpmbuild of the python-2.6.1
Hello,
I'm not subscribed to this list, but this is the best place I could
think of to send this. Please feel free to ignore if this has already
been addressed, or if I've approached it completely wrong.
When trying to perform an rpmbuild of the python-2.6.1 tarball on my
CentOS 5.1 sys
+1 indeedy.
On Sat, Jan 24, 2009 at 5:22 PM, Nick Coghlan wrote:
> Brett Cannon wrote:
>> On Sat, Jan 24, 2009 at 14:46, Raymond Hettinger wrote:
>>> I would like to deprecate some outdated functions in the operator module.
>>>
>>> The isSequenceType(), isMappingType(), and isNumberType()
>>> fu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 25, 2009, at 1:37 PM, Martin v. Löwis wrote:
(*) I'm probably missing something, but ISTM that committers can
already
use the DVCS - they only need to create a patch just before
committing.
This, of course, is somewhat more complicated tha
On Sun, Jan 25, 2009 at 13:03, Michael Foord wrote:
> Brett Cannon wrote:
>>
>> On Sun, Jan 25, 2009 at 10:37, "Martin v. Löwis"
>> wrote:
>>
There's a possible third way. I've heard (though haven't investigated)
that some people are working on supporting the svn wire protocol in
Roumen Petrov wrote:
Cesare Di Mauro wrote:
Have you made some benchmarks like pystone?
Its seems to me version 2.6.1 is not optimized build so I
remove(uninstall) it.
I repeat the pystone tests with an optimized GCC(mingw32) build.
- python-trunk-GCC(mingw32, local, native, optimized)
--
Brett Cannon wrote:
On Sun, Jan 25, 2009 at 10:37, "Martin v. Löwis" wrote:
There's a possible third way. I've heard (though haven't investigated)
that some people are working on supporting the svn wire protocol in the
bzr server. This would mean that anybody who's still comfortable with
s
On Sun, Jan 25, 2009 at 10:37, "Martin v. Löwis" wrote:
>> There's a possible third way. I've heard (though haven't investigated)
>> that some people are working on supporting the svn wire protocol in the
>> bzr server. This would mean that anybody who's still comfortable with
>> svn and feels n
Hello, python-dev!
My name is Ross Light. I was a documentation contributor at GHOP a
couple years back and I wanted to start contributing to the core
interpreter.
I found Issue 4285 and decided to write a patch for it. This is my
first patch, so I'd like someone to review my patch and make sur
> Luke Kenneth Casson Leighton schrieb:
> > i mean... has anyone _written_ a third party module that returns
> > Py_None on a c-code module and had it compiled on windows?
> Lot's of people have written 3rd party extensions that work on Windows
> and can return a Py_None object.
ahh - ok. so.
Hello, python-dev!
My name is Ross Light. I was a documentation contributor at GHOP a
couple years back and I wanted to start contributing to the core
interpreter.
I found Issue 4285 and decided to write a patch for it. This is my
first patch, so I'd like someone to review my patch and make sur
Martin v. Löwis v.loewis.de> writes:
> In
> essence, committers wanting to use a DVCS can do so today, by acting
> as if they were non-committers, and only using svn for actual changes
> to the master repository.
Indeed. It is how I work.
Regards
Antoine.
_
> On Sun, Jan 25, 2009 at 9:01 AM, Matthieu Brucher
> wrote:
> > 2009/1/25 Luke Kenneth Casson Leighton :
> >> according to the wikipedia entry on dlls, dlls do not support data,
> >> only functions.
> >
> > What do you mean by "not support data"? Having global data variables in a
> > dll?
> > I
> There's a possible third way. I've heard (though haven't investigated)
> that some people are working on supporting the svn wire protocol in the
> bzr server. This would mean that anybody who's still comfortable with
> svn and feels no need to change their current habits can continue to
> work
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 25, 2009, at 12:44 PM, Antoine Pitrou wrote:
Barry Warsaw python.org> writes:
Besides, certain developments like support for the svn wire
protocol
in bzr would make the WFC (we fear change :) argument moot.
This is an argument *agains
Barry Warsaw python.org> writes:
> >>
> >> Besides, certain developments like support for the svn wire protocol
> >> in bzr would make the WFC (we fear change :) argument moot.
> >
> > This is an argument *against* the usefulness of switching!
>
> Why?
>
> This simply allows those who are happy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 25, 2009, at 11:49 AM, Antoine Pitrou wrote:
Barry Warsaw python.org> writes:
Besides, certain developments like support for the svn wire protocol
in bzr would make the WFC (we fear change :) argument moot.
This is an argument *against*
On Sun, Jan 25, 2009 at 3:55 PM, Roumen Petrov
wrote:
> Luke Kenneth Casson Leighton wrote:
[SNIP]
Yes it is enough to encapsulate memory allocation and file functions
into
python shared library. The python provide memory allocation functions,
but
not all modules
Luke Kenneth Casson Leighton schrieb:
> i mean... has anyone _written_ a third party module that returns
> Py_None on a c-code module and had it compiled on windows?
Lot's of people have written 3rd party extensions that work on Windows
and can return a Py_None object.
Please stop spamming the
On Sun, Jan 25, 2009 at 9:01 AM, Matthieu Brucher
wrote:
> 2009/1/25 Luke Kenneth Casson Leighton :
>> according to the wikipedia entry on dlls, dlls do not support data,
>> only functions.
>
> What do you mean by "not support data"? Having global data variables in a dll?
> In wikipedia, it is exp
2009/1/25 Luke Kenneth Casson Leighton :
> according to the wikipedia entry on dlls, dlls do not support data,
> only functions.
What do you mean by "not support data"? Having global data variables in a dll?
In wikipedia, it is explicitely told that this is possible to have
data (http://en.wikiped
On Sun, Jan 25, 2009 at 4:33 PM, Luke Kenneth Casson Leighton
wrote:
>> Info: resolving __Py_NoneStruct by linking to __imp___Py_NoneStruct
>> (auto-import)
>
> by no small coincidence, every single module with which we've had
> difficulties in the mingw port - _sre, thread, operator, locale,
>
Luke Kenneth Casson Leighton lkcl.net> writes:
>
> that means that the Py_None macro must call the "getter" function.
Given the negative performance implications that it would have, chances are it
is out of question.
Also, while not a Windows expert *at all*, I'd question your interpretation of
> here is a starting list of data items which will require "getter"
> functions, found just by creating a posixmodule.pyd:
>
> Info: resolving __Py_NoneStruct by linking to __imp___Py_NoneStruct
> (auto-import)
by no small coincidence, every single module with which we've had
difficulties in the
On Sun, Jan 25, 2009 at 3:58 PM, Luke Kenneth Casson Leighton
wrote:
> according to the wikipedia entry on dlls, dlls do not support data,
> only functions. which would explain two things:
> 1) why certain modules are forcibly linked into pythonNN.dll
> 2) why attempts to move them out of pythonN
according to the wikipedia entry on dlls, dlls do not support data,
only functions. which would explain two things:
1) why certain modules are forcibly linked into pythonNN.dll
2) why attempts to move them out of pythonNN.dll cause runtime crashes.
so i will continue the experiment, and remove all
Luke Kenneth Casson Leighton wrote:
[SNIP]
Yes it is enough to encapsulate memory allocation and file functions into
python shared library. The python provide memory allocation functions, but
not all modules use them. File functions are hiden by posixmodule and python
modules can't use them.
ex
> Have you made some benchmarks like pystone?
> Cheers,
> Cesare
Cesare, hi, thanks for responding: unfortunately, there's absolutely
no point in making any benchmark figures under an emulated environment
which does things like take 2 billion instruction cycles to start up a
program named "c:/msy
> decoupling posixmodule.c from pythonNN.dll leaves the possibility to
> make python independent of msvcrt versioning.
>
> it would need to be a custom-compiled .pyd module, due to the early
> dependency.
>
> i'll see if this is possible.
i'd added PyExc_OSError, for example, as data exported fro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 24, 2009, at 7:48 PM, Brett Cannon wrote:
As part of my impressions I plan to also look at usage on top of svn
as a viable alternative if no clear winner comes about. That way if
they work well directly on top of svn we can write up very clea
>> [SNIP]
>> Yes it is enough to encapsulate memory allocation and file functions into
>> python shared library. The python provide memory allocation functions, but
>> not all modules use them. File functions are hiden by posixmodule and python
>> modules can't use them.
>
> except ... posixmodule
On Sun, 25 Jan 2009 02:33:37 pm Raymond Hettinger wrote:
> > Raymond Hettinger wrote:
> >> Since I expect students to be among the users for the comb/perm
> >> functions, there is some merit to keeping the API as simple as
> >> possible. Besides, it is not hard to use the existing tool as a
> >> p
On 24 Jan, 2009, at 22:03, s...@pobox.com wrote:
I'm working on issue 4111 which will add dtrace support to Python when
requested by the builder and when supported by the platform
(currently just
Solaris and Mac OSX I believe).
Sun and Apple have quite different ways to generate the code
44 matches
Mail list logo
