> 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
>> 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
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
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
[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: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
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 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
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 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
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
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 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
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:
>
> > #--
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
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"
>
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
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
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.
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
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
21 matches
Mail list logo
