Ka-Ping Yee <[EMAIL PROTECTED]> writes:
> Client-side web scripting tends to have a callback/continuation-ish
> concurrency style because it has to deal with network transactions
> (which can stall for long periods of time) in a user interface that
> is expected to stay always responsive. The Fir
"A.M. Kuchling" <[EMAIL PROTECTED]> writes:
> On Mon, Jul 10, 2006 at 05:13:53PM +0200, Armin Rigo wrote:
>> didn't draw much applause. It certainly gave me the impression that
>> many changes in Python are advocated and welcomed by only a small
>> fraction of users.
>
> The benefits of changes a
No real time to respond in detail here, but one small comment.
[EMAIL PROTECTED] writes:
> I see some responses to that post which indicate that the specific bug will be
> fixed, and that's good, but there is definitely a pattern he's talking about
> here, not just one issue. I think there is a
[EMAIL PROTECTED] writes:
> I just would have appreciated the opportunity to participate in the
> discussion before the betas were out and the featureset frozen.
I think something that has happened to some extent with this release
is that there was a long-ish period where stuff got discussed and
The next PyPy sprint will happen in the nice city of
Limerick in Ireland from 21st till 27th August.
(Most people intend to arrive 20th August).
The main focus of the sprint will be on JIT compiler works,
various optimization works, porting extension modules,
infrastructure works like a buil
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> On 7/25/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> >
>> > Yes, I definitely think dropping the X would make the warning go away.
>> > Do we want to check for a NULL pointer and raise an exception? The
>> > docs don't address the issue, so I th
Anthony Baxter <[EMAIL PROTECTED]> writes:
> On Friday 28 July 2006 15:32, Raymond Hettinger wrote:
>> I suggest that there be a third beta release and that we then wait
>> just a bit before going final.
>>
>> The bugs that were found and fixed in the first two beta releases
>> suggest that Py2.5
David Hopwood <[EMAIL PROTECTED]> writes:
> Armin Rigo wrote:
>> Hi,
>>
>> There is an oversight in the design of __index__() that only just
>> surfaced :-( It is responsible for the following behavior, on a 32-bit
>> machine with >= 2GB of RAM:
>>
>> >>> s = 'x' * (2**100) # works!
>
Duncan Booth <[EMAIL PROTECTED]> writes:
> Does Coverity recognise objects on Python's internal pools as deallocated?
Coverity doesn't work on that level; it analyzes source code, and
knows about Python's INCREFs and DECREFs.
> The moral is to regard the reference counting rules as law: no matt
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> The point here is that a typical user won't expect any comparisons
> to be made when dealing with dictionaries, simply because the fact
> that you do need to make comparisons is an implementation detail.
Of course looking things up in a dictionary inv
Michael Chermside <[EMAIL PROTECTED]> writes:
> I'm changing the subject line because I want to convince everyone that
> the problem being discussed in the "unicode hell" thread has nothing
> to do with unicode and strings. It's all about dicts.
I'd say it's more to do with __eq__. It's a strang
Neal Becker <[EMAIL PROTECTED]> writes:
> 1) Should assignment to a temporary object be allowed?
The question doesn't make sense: in Python, you assign to a name,
an attribute or a subscript, and that's it.
Cheers,
mwh
--
I think there's a rather large difference between a stale
"Jim Jewett" <[EMAIL PROTECTED]> writes:
>> It wasn't my idea to stop ignoring exceptions in dict lookups; I would
>> gladly have put this off until Py3k, where the main problem
>> (str-unicode __eq__ raising UnicodeError) will go away.
>
>> But since people are adamant that they want this in soon
"A.M. Kuchling" <[EMAIL PROTECTED]> writes:
> On Mon, Aug 21, 2006 at 12:24:54PM -0700, Brett Cannon wrote:
>> As for the docs, they just need a thorough updating.
>
> Michael Hudson was working on a new guide to extending/embedding
> Python. Incorporating
"Gustavo Carneiro" <[EMAIL PROTECTED]> writes:
> According to [1], all python needs to do to avoid this problem is
> block all signals in all but the main thread;
Argh, no: then people who call system() from non-main threads end up
running subprocesses with all signals masked, which breaks other
"Gustavo Carneiro" <[EMAIL PROTECTED]> writes:
> On 9/4/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
>> "Gustavo Carneiro" <[EMAIL PROTECTED]> wrote:
>> > I am now thinking of something along these lines:
>> > typedef void (*PyPendingCallNotify)(void *user_data);
>> > PyAPI_FUNC(void) Py_AddPend
"Michael Urman" <[EMAIL PROTECTED]> writes:
> Hi folks,
>
> Between 2.4 and 2.5 the behavior of file or open with the mode 'wU'
> has changed. In 2.4 it silently works. in 2.5 it raises a ValueError.
> I can't find any more discussion on it in python-dev than tangential
> mentions in this thread:
On 11 Sep 2006, at 09:34, Neal Norwitz wrote:
> Michael,
>
> In Python/pystate.c, you made this checkin:
>
> """
> r39044 | mwh | 2005-06-20 12:52:57 -0400 (Mon, 20 Jun 2005) | 8 lines
>
> Fix bug: [ 1163563 ] Sub threads execute in restricted mode
> basically by fixing bug 1010677 in a non-brok
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Michael Hudson schrieb:
>>> According to [1], all python needs to do to avoid this problem is
>>> block all signals in all but the main thread;
>>
>> Argh, no: then people who call system() from non
Anthony Baxter <[EMAIL PROTECTED]> writes:
> I'd like to propose that the AST format returned by passing PyCF_ONLY_AST to
> compile() get the same guarantee in maintenance branches as the bytecode
> format - that is, unless it's absolutely necessary, we'll keep it the same.
> Otherwise anyone t
Milan Krcmar <[EMAIL PROTECTED]> writes:
> I would like to run Python scripts on an embedded MIPS Linux platform
> having only 2 MiB of flash ROM and 16 MiB of RAM for everything.
>
> Current (2.5) stripped and gzipped (I am going to use a compressed
> filesystem) CPython binary, compiled with def
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> I ignored these as I'm not certain all the platforms we run on accept
> free(NULL).
It's mandated by C99, and I don't *think* it changed from the previous
version (I only have a bootleg copy of C99 :).
Cheers,
mwh
--
TRSDOS: Friendly old lizard. O
[EMAIL PROTECTED] writes:
> I hope that eventually Python will include some form of OO
> filesystem access, but I am equally hopeful that the current PEP 355
> path.py is not it.
I think I agree with this too. For another source of ideas there is
the 'py.path' bit of the py lib, which, um, doesn
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Kristján V. Jónsson schrieb:
>> I can't see how this situation is any different from the re-use of
>> low ints. There is no fundamental law that says that ints below 100
>> are more common than other, yet experience shows that this is so,
>> and so
"Mike Klaas" <[EMAIL PROTECTED]> writes:
> [http://sourceforge.net/tracker/index.php?func=detail&aid=1579370&group_id=5470&atid=105470]
>
> Hello,
>
> I'm managed to provoke a segfault in python2.5 (occasionally it just a
> "invalid argument to internal function" error). I've posted a
> traceback
Hopefully by now you have heard of the "Summer of PyPy", our program
for funding the expenses of attending a sprint for students. If not,
you've just read the essence of the idea :-)
However, the PyPy EU funding period is drawing to an end and there is
now only one sprint left where we can sponso
Giovanni Bajo <[EMAIL PROTECTED]> writes:
> Hello,
>
> I spent my last couple of hourse reading several past threads about fpectl.
> If
> I'm correct
>
> 1) fpectl is scheduled for deletion in 2.6.
> 2) The biggest problem is that the C standard says that it's undefined to
> return from a SIGFP
Georg Brandl <[EMAIL PROTECTED]> writes:
> Armin Rigo schrieb:
>> Hi Paul,
>>
>> On Wed, Jan 10, 2007 at 11:10:10PM +, Paul Moore wrote:
>>> How many other projects/packages anticipate *not* migrating to Py3K, I
>>> wonder?
>>
>> FWIW: Psyco.
>
> What will PyPy do? It will certainly support
[EMAIL PROTECTED] writes:
> On 10:12 am, [EMAIL PROTECTED] wrote:
>
>>For practical reasons (we have enough work to be getting on with) PyPy
>>is more-or-less ignoring Python 2.5 at the moment. After funding and
>>so on, when there's less pressure, maybe it will seem worth it. Not
>>soon though.
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Neil Toronto wrote:
>> I imagine this would be important to someone expecting system resources
>> to be cleaned up, closed, deallocated, or returned inside of __del__
>> methods. Someone coming from C++ might expect LIFO behavior because
>> common idio
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Bug #1579370 reports a crash when accessing the thread state of
> a terminated thread, when releasing a generator object.
>
> In analysing the problem, I found that f_tstate doesn't have much
> utility: it is used in very few places, and in these pla
Giovanni Bajo <[EMAIL PROTECTED]> writes:
> On 23/01/2007 10.20, Brian Warner wrote:
>
Do I miss something here, or is the buildbot hit by spammers now?
>>> It looks like it is. If that continues, we have to disable the web
>>> triggers.
>>
>> Good grief. If anyone has any bright ideas about
Neal Norwitz gmail.com> writes:
>
> Can you call PyMem_FREE() without the GIL held? I couldn't find it
> documented either way.
Nope. See comments at the top of Python/pystate.c.
Cheers,
mwh
___
Python-Dev mailing list
Python-Dev@python.org
http:/
"Edward C. Jones" <[EMAIL PROTECTED]> writes:
> I have a PC with an AMD cpu and Mandrake 10.1. While installing Python
> 2.4 "make test" failed in "test_shutils.py". Here is the output of
> "./python ./Lib/test/test_shutil.py":
Are you running 'make test' as root? Don't do that (although possibl
"Brett C." <[EMAIL PROTECTED]> writes:
> I noticed that Makefile.pre.in uses the value from the environment
> variable LDFLAGS but not CPPFLAGS. Any reason for this?
> ./configure -h`` lists both (and some other environment variables
> which are not really used either) so it seems a little mislea
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Anthony Baxter wrote:
>> The library docs for, e.g. xmllib already say deprecated at the top - maybe
>> it should be larger?
>
> I think it would be better to *remove* the xmllib documentation.
> Existing code which needs the module will continue to
[EMAIL PROTECTED] writes:
> Update of /cvsroot/python/python/dist/src/Lib/test
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20531
>
> Modified Files:
> test_shutil.py
> Log Message:
> SF bug #1076467: don't run test_on_error as root, as the permission
> errors don't get provoked
Andreas Jung <[EMAIL PROTECTED]> writes:
> While using Zope 2.7 with Python 2.4 we discovered some strange
> behaviour of the security machinery.
> I could track this down to some Zope code in cAccessControl.c where an
> Unauthorized exception is
> raised because of a call to PyInt_FromLong(1) whi
"Robert Brewer" <[EMAIL PROTECTED]> writes:
> Anthony Baxter wrote:
>> FWIW, I was planning on writing a tutorial (working title:
>> "Making Python Code Not Suck") for some conference
>> or another...
>
> Perhaps, given your high profile in the Python developer community, you
> might reconsider th
Jeremy Hylton <[EMAIL PROTECTED]> writes:
> I agree, although it's not clear to me how much faster it will be in
> the future. Making a *fast* Python based on our own virtual execution
> environment (as opposed to piggybacking a JVM or CLR) is a big
> project. It's not clear than anyone has enou
Keith Dart <[EMAIL PROTECTED]> writes:
> I did modify the readline module that hooks this and can call back
> to a Python function. There are also methods for installing and
> removing the Python function. I did this for a different reason. I
> need Python signal handlers to run, and they don't ru
Keith Dart <[EMAIL PROTECTED]> writes:
> A.M. Kuchling wrote:
>> On Sun, Dec 12, 2004 at 03:32:03PM -0200, Carlos Ribeiro wrote:
>>
>>>Of course, the point here is not Perl-bashing. The point here is that
>>>we should be able to "sell" Python better than we do now, even without
>>>the need to res
Josiah Carlson <[EMAIL PROTECTED]> writes:
> Quick questions:
> Is mmap's inability to be subclassed a feature or bug?
Like Martin said, a missing feature. I'd also quite like the mmap
module to have a C API, but as my use case is especially evil (
http://starship.python.net/crew/mwh/hacks/PPY.
Titus Brown <[EMAIL PROTECTED]> writes:
> -> > 1067760 -- float-->long conversion on fileobj.seek calls, rather than
> -> >float-->int. Permits larger floats (2.0**62) to match large
> -> >int (2**62) arguments. rhettinger marked as "won't fix" in
> -> >the original bug r
Titus Brown <[EMAIL PROTECTED]> writes:
> -> > Apparently file.seek doesn't have this DeprecationWarning though..
> -> > Strange, that.
> -> > >>> f.seek(3.6)
> -> > >>> f.tell()
> -> > 3L
> ->
> -> That's a bug. Who'll fix it?
>
> Added:
>
> + if (PyFloat_Check(offobj))
> +
Barry Scott <[EMAIL PROTECTED]> writes:
> I recursive grep'ed and missed this ref. However I did read this in
> README.TXT:
The top-level README file is hilariously out-of-date, in some ways. I
meant to do something about this before 2.4 final, but didn't get
around to it...
Cheers,
mwh
--
Armin Rigo <[EMAIL PROTECTED]> writes:
> Hi,
>
> On Fri, Dec 24, 2004 at 12:17:49AM +, Barry Scott wrote:
>> I recursive grep'ed and missed this ref. However I did read this in
>> README.TXT:
>
> The "extending and embedding" tutorial is similarily out-of-date.
Well, I've half re-written tha
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Bob Ippolito wrote:
>> It doesn't for reasons I care not to explain in depth, again.
>> Search the pythonmac-sig archives for longer explanations. The
>> gist is that you specifically do not want to link directly to the
>> framework at all when b
Ilya Sandler <[EMAIL PROTECTED]> writes:
> A problem:
>
> The current struct.unpack api works well for unpacking C-structures where
> everything is usually unpacked at once, but it
> becomes inconvenient when unpacking binary files where things
> often have to be unpacked field by field. Then one
Bob Ippolito <[EMAIL PROTECTED]> writes:
> On Jan 6, 2005, at 8:17, Michael Hudson wrote:
>
>> Ilya Sandler <[EMAIL PROTECTED]> writes:
>>
>>> A problem:
>>>
>>> The current struct.unpack api works well for unpacking C-structures
>
Thomas Heller <[EMAIL PROTECTED]> writes:
>> Bob Ippolito <[EMAIL PROTECTED]> writes:
>
>>> This is my ctypes-like attempt at a high-level interface for struct.
>>> It works well for me in macholib:
>>> http://svn.red-bean.com/bob/py2app/trunk/s
Alex Martelli <[EMAIL PROTECTED]> writes:
> I didn't know about the "let the object lie" quirk in isinstance. If
> that quirk is indeed an intended design feature, rather than an
> implementation 'oops', it might perhaps be worth documenting it more
> clearly; I do not find that clearly spelled o
Guido van Rossum <[EMAIL PROTECTED]> writes:
> To be honest, I don't recall the exact reasons why this wasn't fixed
> in 2.2; I believe it has something to do with the problem of
> distinguishing between string and class exception, and between the
> various forms of raise statements.
A few months
Guido van Rossum <[EMAIL PROTECTED]> writes:
> [Michael]
>> It would still be worth doing, IMHO.
>
> Then let's do it. Care to resurrect your patch? (And yes, classic
> classes should also be allowed for b/w compatibility.)
I found it and uploaded it here:
http://starship.python.net/crew/mwh
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Guido van Rossum wrote:
a) Is Exception to be new-style?
>>>
>>>Probably not in 2.5; Martin and others have suggested that this could
>>>introduce instability for users' existing exception classes.
>> Really? I thought that was eventually decided
Michael Hudson <[EMAIL PROTECTED]> writes:
> I hope to have a new patch (which makes PyExc_Exception new-style, but
> allows arbitrary old-style classes as exceptions) "soon". It may even
> pass bits of "make test" :)
Done: http://www.python.org/sf/110466
Donovan Baarda <[EMAIL PROTECTED]> writes:
> G'day,
>
> I've Cc'ed this to zope-coders as it might affect other Zope developers
> and it had me stumped for ages. I couldn't find anything on it anywhere,
> so I figured it would be good to get something into google :-).
>
> We are developing a Zope2
Donovan Baarda <[EMAIL PROTECTED]> writes:
> On Wed, 2005-01-19 at 13:37 +, Michael Hudson wrote:
>> Donovan Baarda <[EMAIL PROTECTED]> writes:
> [...]
>> You've left out a very important piece of information: which version
>> of Python you are usi
Donovan Baarda <[EMAIL PROTECTED]> writes:
> On Thu, 2005-01-20 at 14:12 +, Michael Hudson wrote:
>> Donovan Baarda <[EMAIL PROTECTED]> writes:
>>
>> > On Wed, 2005-01-19 at 13:37 +, Michael Hudson wrote:
>> >> Donovan Baarda <[EMAIL
Paul Moore <[EMAIL PROTECTED]> writes:
> Also, while looking at patches I noticed 1077106. It doesn't apply to
> me - I don't use Linux - but it looks like this may have simply been
> forgotten. The last comment is in December from from Michael Hudson,
> saying
Evan Jones <[EMAIL PROTECTED]> writes:
> On Jan 31, 2005, at 0:17, Guido van Rossum wrote:
>> The "just kidding" applies to the whole list, right? None of these
>> strike me as good ideas, except for improvements to function argument
>> passing.
>
> Really? You see no advantage to moving to garbag
[EMAIL PROTECTED] writes:
> Update of /cvsroot/python/python/dist/src/Python
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26507/Python
>
> Modified Files:
> compile.c
> Log Message:
> Transform "x in (1,2,3)" to "x in frozenset([1,2,3])".
>
> Inspired by Skip's idea to recognize
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 08:20 PM 2/9/05 +0100, BJörn Lindqvist wrote:
>>Does Skip's idea have
>>any merit?
>
> Yes, but not as a default behavior. Many people already consider the
> fact that tracebacks display file paths to be a potential security
> problem. If anythin
Jim Jewett <[EMAIL PROTECTED]> writes:
> On Wed, 09 Feb 2005 17:42:41 -0800, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>> Update of /cvsroot/python/python/dist/src/Python
>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31172
>>
>> Modified Files:
>> compile.c
>> Log Message:
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> does anyone remember if there were any big changes in pymalloc between
> the 2.1 series (where it was introduced) and 2.3 (where it was enabled by
> default).
Yes. (Was it really 2.1? Time flies!)
> or in other words, is the 2.1.3 pymalloc stable e
Michael Hudson <[EMAIL PROTECTED]> writes:
> Michael Hudson <[EMAIL PROTECTED]> writes:
>
>> I hope to have a new patch (which makes PyExc_Exception new-style, but
>> allows arbitrary old-style classes as exceptions) "soon". It may even
>&
Guido van Rossum <[EMAIL PROTECTED]> writes:
>> My design decision was to make Exception new-style. Things can be
>> raised if they are instances of old-style classes or instances of
>> Exception. If this meets with general agreement, I'd like to check
>> the above patch in.
>
> I like it, but d
Nick Rasmussen <[EMAIL PROTECTED]> writes:
[five days ago]
> Should boost::python functions be modified in some way to show
> up as builtin function types or is the right fix really to patch
> pydoc?
My heart leans towards the latter.
> Is PyCFunction_Type intended to be subclassable?
Doesn't
Tim Peters <[EMAIL PROTECTED]> writes:
> Rev 2.66 of funcobject.c made func.__name__ writable for the first
> time. That's great, but the patch also introduced what I'm pretty
> sure was an unintended incompatibility: after 2.66, func.__name__ was
> no longer *readable* in restricted execution m
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Nick Coghlan wrote:
>
>>> One thing that actually can motivate that test_subprocess takes 20% of the
>>> overall time is that this test is a good generic Python stress test - this
>>> test might catch some other startup race condition, for example.
>>
Tim Peters <[EMAIL PROTECTED]> writes:
> [Michael Hudson]
>> ...
>> Well, I fixed it on reading the bug report and before getting to
>> python-dev mail :) Sorry if this duplicated your work, but hey, it was
>> only a two line change...
>
> Na, the real wor
Tim Peters <[EMAIL PROTECTED]> writes:
> [sorry for the near-duplicate msgs -- looks like gmail lied when it claimed
> the
> first msg was still in "draft" status]
>
>>> Did you add a test to ensure this remains fixed?
>
> [mwh]
>> Yup.
>
> Bless you. Did you attach a contributor agreement and
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
>> Let's keep the really long-running tests out
>> of the regular test suite.
>
> For test_subprocess, consider adopting the technique used by
> test_decimal. When -u decimal is not specified, a small random
> selection of the resource intensive tes
Nick Coghlan <[EMAIL PROTECTED]> writes:
> This is something I've typed way too many times:
>
> Py> class C():
>File "", line 1
> class C():
> ^
> SyntaxError: invalid syntax
>
> It's the asymmetry with functions that gets to me - defining a
> function with no arguments still
Alex Martelli <[EMAIL PROTECTED]> writes:
> On 2005 Feb 20, at 04:35, Jack Diederich wrote:
>
>> I didn't dig into the C but does having 'type'
>> as metaclass guarantee the same behavior as inheriting 'object' or
>> does object
>> provide something type doesn't? *wince*
>
> I believe the forme
Guido van Rossum <[EMAIL PROTECTED]> writes:
>> Any objections to new peephole transformation that merges a store/load
>> pair into a single step?
>>
>> There is a tested patch at: www.python.org/sf/1144842
>>
>> It folds the two steps into a new opcode. In the case of
>> store_name/load_name,
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 08:17 AM 2/20/05 -0800, Guido van Rossum wrote:
>>Where are the attempts to speed up function/method calls? That's an
>>area where we could *really* use a breakthrough...
>
> Amen!
>
> So what happened to Armin's pre-allocated frame patch? Did tha
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 07:00 PM 2/20/05 +0000, Michael Hudson wrote:
>>"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
>>
>> > At 08:17 AM 2/20/05 -0800, Guido van Rossum wrote:
>> >>Where are the atte
Michael Hudson <[EMAIL PROTECTED]> writes:
>> Because there are CO_MAXBLOCKS * 12 bytes in there for the block
>> stack. If there was no need for that, frames could perhaps be
>> allocated via pymalloc. They only have around 100 bytes or so in
>> them, apart from t
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Neil Schemenauer wrote:
>> IMO, Decimal should
>> be returning NotImplemented instead of raising TypeError.
>
> I agree, but I'm also interested in the fact that nobody commented on
> this before Python 2.4 went out. I read the reference page on numeric
[EMAIL PROTECTED] writes:
> Update of /cvsroot/python/python/dist/src/Python
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22139/Python
>
> Modified Files:
> import.c
> Log Message:
> Patch #1043890: tarfile: add extractall() method.
Uh, did you mean to check import.c in here?
C
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> I just mistakenly checked in import.c; I have "outdated"
> this checkin (cvs admin -o 2.241 import.c). If you happened
> to have checked-out import.c in-between, don't be surprised
> if the version numbers go backwards.
Oh! Oops. python-checkins s
Greg Ward <[EMAIL PROTECTED]> writes:
> On 06 March 2005, I said:
>> I'll check this in and merge to the trunk once I see all tests passing.
>
> Checked in on 2.4 branch. Not merged to trunk since Raymond hasn't
> merged his stuff to the trunk yet.
I don't think that code is going onto HEAD.
Ch
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> Which reminds me, btw, it would be nice while we're adding more
> execution control functions to have a way to get the current trace
> hook and profiling hook,
Well, there's the f_trace member of frame objects, but I honestly
can't remember what it's
Greg Ward <[EMAIL PROTECTED]> writes:
> On 08 March 2005, Michael Chermside said:
>> Greg writes:
>> > This is one of my top two Java features [1].
>> ...
>> > [1] The other is compiler recognition of "@deprecated" in doc comments.
>>
>> Hmm... what a good idea! Let's see... what exactl
"Donovan Baarda" <[EMAIL PROTECTED]> writes:
>
> Just my 2c;
>
> I don't mind new features in minor releases, provided they meet the
> following two criteria;
>
> 1) Don't break the old API! The new features must be pure extensions that in
> no way change the old API. Any existing code should be u
"Irmen de Jong" <[EMAIL PROTECTED]> writes:
> mwh wrote:
>
>
>> One difference: I imagine (hope!) the java compiler would complain if
>> the deprecated function is referenced, whereas the python version only
>> complains if it is called...
>
> The java compiler actually already produces deprecatio
Anthony Baxter <[EMAIL PROTECTED]> writes:
> My google-fu returned, and I found the piece I was looking for earlier.
> This discusses (from an internal Sun perspective) some of the problems
> with Java. They make quite a big deal about the problem of changing
> code across minor releases. I recall
"Donovan Baarda" <[EMAIL PROTECTED]> writes:
> G'day again,
[...]
> You missed the "minor releases" bit in my post.
>
> major releases, ie 2.x -> 3.0, are for things that can break existing code.
> They change the API so that things that run on 2.x may not work with 3.x.
>
> minor releases, ie 2
"Delaney, Timothy C (Timothy)" <[EMAIL PROTECTED]> writes:
> Set: Items are iterated over in the order that they are added. Adding an
> item that compares equal to one that is already in the set does not
> replace the item already in the set, and does not change the iteration
> order. Removing an
Robey Pointer <[EMAIL PROTECTED]> writes:
> (I've been lurking for a while but this is my first post. I maintain
> paramiko and enjoy harrassing people on sourceforge to fix the
> new-style Exception bug that vexes me. Nice to meet you all.) :)
Well, hey, you can review my patch if you like:
It's needed to implement things that behave like instance methods, for
instance, and I notice that at at least some point in the past Zope3
has used the function with a note attached saying "Guido says this is
OK".
Also, the context is that I want to submit a patch to PyObjC using the
function, an
Armin Rigo <[EMAIL PROTECTED]> writes:
> Hi Michael,
>
>> ... _PyType_Lookup ...
>
> There has been discussions about copy_reg.py and at least one other place in
> the standard library that needs this; it is an essential part of the
> descriptor model of new-style classes. In my opinion it should
"Edward C. Jones" <[EMAIL PROTECTED]> writes:
> I had
>
> PyArg_ParseTuple(args, "s#s#i:compare", &p1, &bytes1, &p2, &bytes2)
>
> in a program. There are not enough arguments to PyArg_ParseTuple. Does
> PyArg_ParseTuple know how many arguments it is getting?
I don't think so.
> If so, I suggest
Adam MacBeth <[EMAIL PROTECTED]> writes:
> Has anyone ever considered using SCons to build Python?
Well, er, there's an obvious problem here somewhere...
> SCons is a great build tool written in Python that provides some
> Autoconf-like functionality (http://www.scons.org). It seems like
> this
[EMAIL PROTECTED] writes:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10274
>
> Modified Files:
> readline.c
> Log Message:
> Fixes for
>
> [ 110 ] The readline module can cause python to segfault
>
> It seems to me that th
Asking mostly for curiousity, how hard would it be to have longs store
their sign bit somewhere less aggravating? It seems to me that the
top bit of ob_digit[0] is always 0, for example, and I'm sure this
would result no less convolution in longobject.c it'd be considerably
more localized convolut
Tim Peters <[EMAIL PROTECTED]> writes:
> [Michael Hudson]
>> Asking mostly for curiousity, how hard would it be to have longs store
>> their sign bit somewhere less aggravating?
>
> Depends on where that is.
>
>> It seems to me that the top bit of ob_digit[
Michael Hudson <[EMAIL PROTECTED]> writes:
> Tim Peters <[EMAIL PROTECTED]> writes:
>
>> [Michael Hudson]
>>> Asking mostly for curiousity, how hard would it be to have longs store
>>> their sign bit somewhere less aggravating?
>>
>> Dep
I recently redid how the readline module handled threads around
callbacks into Python (the previous code was insane).
This resulted in the following bug report:
http://www.python.org/sf/1176893
Which is correctly assigned to me as it's clearly a result of my
recent checkin. However, I think
1 - 100 of 332 matches
Mail list logo
