On 2 May 2012, at 18:06, Ezio Melotti wrote:
> On 02/05/2012 19.33, Michael Foord wrote:
>> On 2 May 2012, at 16:55, Terry Reedy wrote:
>>> I would send the above to webmas...@python.org (should be at the bottom of
>>> pages). We develop CPython but do not directly
me - surely?
The executable path is normally available in sys.executable.
Michael
>
> Of course argv[0] is normally set to the executable's path, but there's at
> least
> one test (in test_sys) where Python is spawned (via subprocess) with argv[0]
> set
> to "
e, and I see tildes
> used elsewhere, so I guess it's some reST/docutils magic. I left this one in
> there.
>
It means display the link with the text "namedtuple" instead of the full
"collections.namedtuple". You can't just omit the &
ate to change the name of the 'metaclass' keyword to
> 'factory', but we could use that terminology in the docs.
Well, the same was always true in Python 2 as well - __metaclass__ could be a
function that was identically "silly". The real "metaclass" (
ore likely to
> achieve the necessary level of consensus.
>
> As a specific example, the unittest module could use it to provide
> test parameterisation without needing a custom metaclass.
Heh, you're effectively restoring the old Python 2 metaclass machinery with a
slightly-less
I don't think functools.wraps can copy the signature by default - it's not
uncommon to have decorators that modify signatures. A new parameter to
functools.wraps defaulting to False?
Michael
> -
> Yury
> ___
> Python-
ements to be had. So tracing JITs are not the *whole* of the
state of the art.
Michael
> Regards,
> Martin
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> U
On 20 Jul 2012, at 17:50, Maciej Fijalkowski wrote:
> On Fri, Jul 20, 2012 at 2:55 PM, Michael Foord
> wrote:
>
> On 17 Jul 2012, at 23:04, mar...@v.loewis.de wrote:
>
> >> [snip...]
> >
> >> I would like to use a JIT to generate specialized functi
continue to be correct)? Just because something is implementation dependent
doesn't mean it should not be tested - instead the tests should be marked as
cpython specific so that they aren't executed on other implementations.
All the best,
Michael
>
ough to convert files
> without further intervention and testing.
It is if you design your code *to be converted* by 2to3 and do regular testing
of the result.
Michael
>
> --
> Terry Jan Reedy
>
>
>
> ___
> Python-De
On 24 Jul 2012, at 11:52, Devin Jeanpierre wrote:
> On Tue, Jul 24, 2012 at 6:07 AM, Michael Foord
> wrote:
>>> This is not an ideal world and 2to3 is not good enough to convert files
>>> without further intervention and testing.
>>
>> It is if you design
; changing mode of build/scripts-2.7/2to3 from 644 to 755
> changing mode of build/scripts-2.7/smtpd.py from 644 to 755
> [65930 refs]
>
> However, I can't find the python it's built...
It should be python.exe (yes really).
After the build you should be able to do:
On Nov 5, 2012, at 4:51 PM, Greg Ewing wrote:
> Nick Coghlan wrote:
>> On Mon, Nov 5, 2012 at 10:08 PM, Mark Dickinson wrote:
>>> In Python 2, the 'exec' statement supports 'exec'-ing a (statement,
>>> globals, locals) tuple:
>
> If this is a deliberate feature, I'd guess it's because exec
> is
There's a problem with the instructions for using Active TCL with Python for
the Mac.
Michael
Begin forwarded message:
> From: "Dr. Anthony G. Francis, Jr."
> Subject: Broken links on
> http://www.python.org/download/mac/tcltk/#activetcl-8-5-11
> Date: 19 Dece
Hey folks,
Likely the wrong place to report this, but I couldn't work out the best place
and figured this is only as bad as anywhere else.
A user has reported to webmaster that hgweb is misconfigured (or at least the
server configuration is interfering with hgweb).
The symptom is that this url
think it provides a
real advantage giving it's limitations (doesn't work for import'ed
modules, classes + methods != module, etc.).
Cheers,
Michael
On Fri, 3 Dec 2004 11:54:25 +0200 (EET), Stelios Xanthakis
<[EMAIL PROTECTED]> wrote:
>
> Hi all.
>
> Now that
"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
If I parse you correctly, this would be great.
- Michael
On Thu, 09 Dec 2004 16:37:59 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> At 04:11 PM 12/9/04 -0500, Glyph Lefkowitz wrote:
>
>
> >On Wed, 2004-12-08 at 17:39 -0500, Phillip J. Eby wrote:
> >
> > &
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
On Thu, 16 Dec 2004 06:13:41 -0700, Stewart Midwinter
<[EMAIL PROTECTED]> wrote:
> [...] Possible slogan for Python: "Fast enough, and better in many ways".
> [...]
Let's make it faster first :-)
Cheers,
Michael
___
Pyt
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
but which at the same time manages to
associate the word "fast" with "Python".
-- Michael Chermside
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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
they don't even know C. That's a
lot to filter through for such people. (After all, I
sure HOPE that only a small fraction of checkins are for
PEPs not code.)
I'm +0 on it... but I'll mention that if such a list were
created I'd subscribe. So maybe that's +0.2 in
Can't we treat this misbehavior as an outright bug?
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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
t and let's see if that does the trick.
I just got notification of the change to PEP 246 (and I haven't received
other checkin notifications), so I guess I can report that this is
working.
Thanks, Barry. Should we now mention this on c.l.py for others who
ma
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
But in my world, people occasionally misuse
adaptation because they think they know what they're doing
or because they're in a big hurry and it's the most convenient
tool at hand.
I wish I lived in your world, but I don't.
-- Michael Chermside
[1] - Except for Eiffel.
than class inheritance (which of course is used more
> often). Do you want to prohibit interface inheritance, too?
Hmm. Sounds like you're making a point here that's important, but which
I don't quite get. Can you elaborate? I certainly hadn't intended to
prohibit interf
st, but "LiskovViolation" in the exception name seems unbeatably
clear and concise.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
" in this case short
of prohibiting interface inheritance entirely. And, as Phillip points
out to me (see above) this is a more common type of error.
Gee... I'm understanding the problem a little better, but elegant
solutions are still escaping me.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
s not true.
Guido writes:
> How about SubstitutabilityError?
It would be less precise and informative to ME but apparently more so
to a beginner. Obviously, we should support the beginner!
-- Michael Chermside
___
Python-Dev mailing lis
too NIMPY-ish . What am I missing?
Sleepingly yours,
Michael
On Wed, 12 Jan 2005 23:48:47 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> At 11:26 PM 1/12/05 -0500, Clark C. Evans wrote:
> >Regardless,
> >getting back to the main goal I had when writing PEP 246 -- your
On Thu, 13 Jan 2005 01:04:01 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> At 12:01 AM 1/13/05 -0500, Michael Walter wrote:
> >What am I missing?
>
> The fact that this is a type-declaration issue, and has nothing to do with
> *how* types are checked.
I was talking ab
would like to manifest
that in the type instead of implicitely by the code). Your concept is
cool, tho :-)
Michael
On Thu, 13 Jan 2005 08:52:21 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> At 10:18 PM 1/13/05 +1000, Nick Coghlan wrote:
> >Michael Walter wrote:
> >>Y
he
> first place, either...
+1. Writing a default __conform__ for object is reasonable.
Alex writes:
> I'd rather not make a change to built-in ``object'' a prereq for PEP
246
Why not? Seems quite reasonable. Before __conform__ existed, there
wasn't
one for object
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:
ht
"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
lity, so we
are jumping through hoops to ensure that even this old code which is
violating the rules doesn't get broken.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
good IPC library that makes
it easier to write programs that launch "threads" as separate processes
and communicate with them. No change to the internals, just a new
library to encourage people to use the technique that already works.
-- Michael Chermside
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:
n't comment on whether this applies to libmd.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
"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
But... only as an additional option, not as a replacement, right?
Michael
On Sat, 19 Feb 2005 03:01:14 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > This is something I've typed way too many times:
> > >
> > > Py> class C():
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 +, 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
propose it! Let's alias
map, filter, and reduce into the functional module now that it exists.
This doesn't create any need or pressure to remove these as builtins, but
it does contemplate a day when we might choose to make such a choice.
-- Michael Chermside
[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
y
>>> func(3,4)
Warning (from warnings module):
File "g:/Documents/Personal/Python/deprecated.py", line 10
warnings.warn("Call to deprecated function.")
UserWarning: Call to deprecated function.
7
So... shall I go add this to the cookbook?
-- Michael
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.
"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
arning certainly sounds right, or is there
some reason why I should use a custom subclass of DeprecationWarning?
Michael Hudson and Irmen point out:
> One difference: I imagine (hope!) the java compiler would complain if
> the deprecated function is referenced, whereas the python version
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
locations, repairs, uninstalls, single-user and all-user installs, and
I found no problems anywhere. Nice work!
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
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:
That is like Lisp's +, must be good :P
Michael
On Sun, 13 Mar 2005 08:38:42 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> There are a few design choices we could have made for sum(); in
> particular, for non-empty sequences we could not have used the
> identity e
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-st
1301 - 1400 of 1850 matches
Mail list logo
