Hi,
I think http://www.python.org/dev/peps/pep-3101/ is too liberal with the
choice of fill characters for numerical values. As far as I can see, this
is quite legal:
Python 2.7a0 (trunk:76132M, Nov 6 2009, 15:20:35)
[GCC 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3)] on linux2
Type "he
Stefan Krah wrote:
Hi,
I think http://www.python.org/dev/peps/pep-3101/ is too liberal with the
choice of fill characters for numerical values. As far as I can see, this
is quite legal:
Python 2.7a0 (trunk:76132M, Nov 6 2009, 15:20:35)
[GCC 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3
Eric Smith wrote:
> Stefan Krah wrote:
> >Hi,
> >
> >I think http://www.python.org/dev/peps/pep-3101/ is too liberal with the
> >choice of fill characters for numerical values. As far as I can see, this
> >is quite legal:
> >
> >
> >Python 2.7a0 (trunk:76132M, Nov 6 2009, 15:20:35)
> >[GCC 4.1.3
Hi,
I was wondering what's the status of PEP 382. Is anyone (MvL?) is
going to start to work on its implementation for Python 2.7/3.2
inclusion ?
Regards
Tarek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
Stefan Krah wrote:
> I simply think that apart from rounding, the output of format should not
> change the numerical value of its argument. The format functions in C do
> not allow this to happen. Are there other languages where this is possible?
Actually there are other cases: strfmon() allows t
On Tue, Nov 10, 2009 at 10:07 PM, Greg Ewing
wrote:
> Seems to me the only kind of IDE that it makes sense to
> ship with Python is one that is written in Python and
> maintained by the core developers. Anything else is best
> left as a third party package for download by those
> who want to use i
Stefan Krah wrote:
Eric Smith wrote:
Stefan Krah wrote:
Hi,
I think http://www.python.org/dev/peps/pep-3101/ is too liberal with the
choice of fill characters for numerical values. As far as I can see, this
is quite legal:
Python 2.7a0 (trunk:76132M, Nov 6 2009, 15:20:35)
[GCC 4.1.3 20080
Tarek Ziadé wrote:
I was wondering what's the status of PEP 382. Is anyone (MvL?) is
going to start to work on its implementation for Python 2.7/3.2
inclusion ?
If Martin isn't interested in doing it, I'll take a try at it. But I'll
need some rough guidance on the implementation approach.
Er
Hi all,
I'm using BeautifulSoup to parsing an HTML page and find it refused to
parse the page. By looking at the backtrace, I found it is a problem
with the python built-in HTMLParser.py. In fact, the web page I'm
parsing is with some Chinese characters. there is a tag like , note this is legacy
Hello Zhang Chiyuan,
Can you file a bug on the Python issue tracker please:
http://bugs.python.org
Thanks
Michael Foord
Zhang Chiyuan wrote:
Hi all,
I'm using BeautifulSoup to parsing an HTML page and find it refused to
parse the page. By looking at the backtrace, I found it is a problem
On Tue, Nov 10, 2009 at 5:27 PM, Georg Brandl wrote:
>
> Quite simple: because we can't possibly ship Emacs.
>
> cheers,
> Georg
>
We just need a PyEmacs. Written in python, extensible in elist and
python. Nice and simple ;-D
--
-Brandon Singer
___
P
On Wed, Nov 11, 2009 at 12:59 PM, Echo wrote:
> We just need a PyEmacs. Written in python, extensible in elist and
> python. Nice and simple ;-D
I'd even give up the elisp support if I could have Python in my Emacs.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is w
> I was wondering what's the status of PEP 382. Is anyone (MvL?) is
> going to start to work on its implementation for Python 2.7/3.2
> inclusion ?
I'll be working on an implementation, but contributions are welcome.
Unfortunately, I'm really short on free software time recently (and
keep hoping t
On Wed, Nov 11, 2009 at 1:50 PM, Fred Drake wrote:
> On Wed, Nov 11, 2009 at 12:59 PM, Echo wrote:
>> We just need a PyEmacs. Written in python, extensible in elist and
>> python. Nice and simple ;-D
> I'd even give up the elisp support if I could have Python in my Emacs.
Have you tried Pymacs?
_
Raymond Hettinger wrote:
>
> [MvL]
>>> I personally think that decoupling the releases would be best, i.e.
>>> not start thinking about 3.2 for another 6 months.
>
> [Benjamin]
>> The problem with that is that there is a period of time where 2.x has
>> features which 3.x doesn't. My preference is
On Wed, Nov 11, 2009 at 1:18 PM, Nick Coghlan wrote:
> I think I've decided I don't mind either way, so I'm fine with whichever
> approach is easier for Benjamin and the platform installer builders to
> manage.
+1
--
--Guido van Rossum (python.org/~guido)
___
16 matches
Mail list logo