Gregory P. Smith wrote:
> My main suggestion was going to be the ability to turn it off as you already
> mentioned. However, please consider leaving it off by default to avoid
> problems for installed python scripts importing user supplied code. For
> shared hosting environments where this become
I'm sure you've heard most/all of this before but..it..just..seems..so..true...
Finally this week I've "written" (ported from sh) a bunch of Perl, 2000 sparse
lines.
While it sure beats Perl, it has some glaring flaws, more glaring due to
its overall goodness.
I feel compelled to voice my opinio
This is a VERY VERY rough draft of a PEP. The idea is that there should be
some formal way that reST parsers can differentiate (in docstrings) between
variable/function names and identical English words, within comments.
PEP: XXX
Title: Catching unmarked identifiers in docstrings
Version: 0.0.0.0.
how about that py 2.5.2 release. anybody? =D
On Jan 3, 2008 2:05 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > 3.x fixes, because there's no schedule for 2.6.
> >
> > Eh? PEP 3000 has a schedule that includes 2.6:
>
> OK, no schedule that I knew about :-). I'll get back to work on it.
>
> Bil
On Jan 4, 2008 2:46 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> See http://bugs.python.org/issue1731. Should we consider it safe to
> backport r57216 to 2.5.2? This is Thomas Wouters's code to disable
> spurious tracebacks when daemon threads die. We're running some 2.4
> apps with (a varian
Jay schrieb:
Only addressing the easier points here:
> #--
> # flaw #2
> #
> # In functions, reads are scoped. Writes are not.
> #
>
> A = "1"
>
> def F1():
> A = "2" # not an error
>
> def F2():
> #B = A # error
> A = "3"
>
The previous four posts were dredged out of the holding pen in Mailman.
Sorry for the delay.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/py
It would make more sense to redirect "criticism" out of beginners'
ignorance to comp.lang.python rather than spend time discussing their
misunderstandings here.
On Jan 13, 2008 9:28 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Jay schrieb:
>
> Only addressing the easier points here:
>
> > #--
On 1/13/08, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> Gregory P. Smith wrote:
> > My main suggestion was going to be the ability to turn it off as you
> already
> > mentioned. However, please consider leaving it off by default to avoid
> > problems for installed python scripts importing user
Gregory P. Smith wrote:
>> I also tried to check if os.stat(__main__.__file__).st_uid ==
>> os.getuid() but the real __main__ is not available in site.py. It's
>> loaded and assigned much later.
>
> Is sys.argv[0] available at that point?
No, it's not available, too. The 'site' module is importe
On Jan 12, 2008, at 5:32 PM, Raymond Hettinger wrote:
> Not natural, just inefficient and cute. Also, there was no answer
> to the question about use cases.
Fair enough. I will present some use cases below.
> AFAICT, this feature has never been requested. The closest was a
> feature request f
On Jan 12, 2008 8:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> > During the discussion about the new Rational implementation
> > (http://bugs.python.org/issue1682), Guido and Raymond decided that
> > Decimal should not
I've uploaded a new patch:
http://bugs.python.org/issue1799
Christian
___
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-arc
On Jan 13, 2008 6:12 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> On Jan 12, 2008 8:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> > > During the discussion about the new Rational implementation
> > > (http://bugs
On Jan 13, 2008 3:41 PM, Leif Walsh <[EMAIL PROTECTED]> wrote:
> I haven't been watching the python-dev list for very long, so maybe
> this has already been discussed ad nauseam (in which case, sorry),
> but, from the devil's advocate-ish mathematics side of things, unless
> numbers.Decimal is plan
On Jan 13, 2008 7:26 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> Guido mentioned the possibility briefly at
> http://mail.python.org/pipermail/python-3000/2007-April/007015.html
> ("One could argue that float and Decimal are <:Q, but I'm not sure if
> that makes things better pragmatically") b
[Christian Heimes]
> Log:
> Added new an better structseq representation. E.g. repr(time.gmtime(0)) now
> returns 'time.struct_time(tm_year=1970, tm_mon=1,
> tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)'
> instead of '(1970, 1, 1, 0, 0, 0, 3, 1, 0)'. The
> feature
On Jan 13, 2008 7:53 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Christian Heimes]
> > Log:
> > Added new an better structseq representation. E.g. repr(time.gmtime(0)) now
> > returns 'time.struct_time(tm_year=1970, tm_mon=1,
> > tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday
Raymond Hettinger wrote:
> FWIW, I was looking into something similar but didn't proceed because it
> would break eval(repr(s)) == s as the constructor signature
> wants all the args in a tuple and won't accept keywords. Still, I think what
> you did is a nice improvement.
I agree that eval(re
>> 1. Have structseq subclass from PyTupleObject so that isinstance(s, tuple)
>> returns True. This makes the object usable whenever
>> tuples are needed.
>
> Hmm, is that really necessary? structseq has been in use for quite a
> while and this need hasn't come up -- it's been designed to be qui
> Hmm, is that really necessary? structseq has been in use for quite a
> while and this need hasn't come up -- it's been designed to be quite
> compatible with tuple *except* for isinstance checks, and that has
> worked well.
In addition, I would like to suggest that the current structseq usage
is
21 matches
Mail list logo
