Guido van Rossum writes:
Really? I would have thought that cell phones have long been the
platforms most supportive of Unicode.
I would think so too, except in Japan.
However, my previous phones exposed file systems with names encoded in
Shift JIS to USB and IR browsers, though. (My
Really? I would have thought that cell phones have long been the
platforms most supportive of Unicode.
I would think so too, except in Japan.
However, my previous phones exposed file systems with names encoded in
Shift JIS to USB and IR browsers, though. (My current one uses
On Mon, Jan 24, 2011 at 6:22 AM, Brett Cannon br...@python.org wrote:
In Getting Set Up it describes how to build a pydebug build. Is that
really necessary for those who plan only to contribute by working on
pure Python code?
Yes, there is actually a laundry list of reasons even people only
Martin v. Löwis writes:
It's one thing how the file systems are formatted, but another thing
how they are presented to APIs. For example, the phones using Windows CE
would have to convert the file names to Unicode in the OS kernel.
So: for these phones - do you know how they present
On Mon, Jan 24, 2011 at 8:35 PM, Stephen J. Turnbull step...@xemacs.org wrote:
First of all, these aren't just phones; these are all kinds of gadgets
(the example I gave was a camera). They're not as smart as an Android
or iPhone-like device, and I don't know what OS they use.
We're getting a
Hi Brett,
On Sat, 22 Jan 2011 17:08:00 -0800
Brett Cannon br...@python.org wrote:
http://docs.python.org/devguide/
Personally, I found the first paragraph of Contributing a bit
off-putting.
How about replacing:
People who wish to contribute to Python must read the following
documents
On Mon, 24 Jan 2011 20:33:07 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Mon, Jan 24, 2011 at 6:22 AM, Brett Cannon br...@python.org wrote:
In Getting Set Up it describes how to build a pydebug build. Is that
really necessary for those who plan only to contribute by working on
pure
Greetings!
I know that this list is for python development questions/comments, but I
wanted to bring up the tahoe-lafs project if people are interested in a project
developed in python that allows for secure distributed storage. For more
information see http://tahoe-lafs.org
For those of you
On Mon, 24 Jan 2011 07:56:56 -0600
Earney, Billy C. ear...@umsystem.edu wrote:
Greetings!
I know that this list is for python development questions/comments, but I
wanted to bring up the tahoe-lafs project [...]
You should really post such messages to comp.lang.python.
On Mon, Jan 24, 2011 at 9:29 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 24 Jan 2011 20:33:07 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Mon, Jan 24, 2011 at 6:22 AM, Brett Cannon br...@python.org wrote:
In Getting Set Up it describes how to build a pydebug build. Is that
On Mon, Jan 24, 2011 at 11:56 PM, Earney, Billy C. ear...@umsystem.eduwrote:
Greetings!
I know that this list is for python development questions/comments,
People that post questions innocently unaware of the nature of this list
have an excuse.
You don't.
This is not a good way to
On Sat, 22 Jan 2011 17:08:00 -0800
Brett Cannon br...@python.org wrote:
Two, what should the final URL be? Georg picked the current one and I
am happy with it.
Ditto for me.
Three, where should it be linked from? docs.python.org homepage?
Four, what to do with www.python.org/dev/? Redirect
Le lundi 24 janvier 2011 11:35:22, Stephen J. Turnbull a écrit :
... VFAT-formatted file systems and Shift JIS file names ...
I missed something: VFAT stores filenames as unicode (whereas FAT only
supports byte filenames). Well, VFAT stores filenames twice: as a 8+3 byte
strings and as a 255
Using:Python 2.7.0+ (r27:82500, Sep 15 2010, 18:14:55) [GCC 4.4.5] on
linux2(Ubuntu 10.10)
Method to reproduce error:
1. Defining a module which is later imported by another:
-
class SomeThing:
def __init__(self):
Le lundi 24 janvier 2011 16:39:39, Victor Stinner a écrit :
Le lundi 24 janvier 2011 11:35:22, Stephen J. Turnbull a écrit :
... VFAT-formatted file systems and Shift JIS file names ...
I missed something: VFAT stores filenames as unicode (whereas FAT only
supports byte filenames). Well,
I want to make it clear that I am in no way associated with the tahoe-lafs
project. I do not want my email to make that project look bad. That was not
my intention.
Billy Earney
ear...@umsystem.edumailto:ear...@umsystem.edu
Programmer/Analyst-Expert
[cid:image001.gif@01C0.03DD8B00] MySQL
On Mon, Jan 24, 2011 at 04:39:39PM +0100, Victor Stinner wrote:
I missed something: VFAT stores filenames as unicode (whereas FAT only
supports byte filenames). Well, VFAT stores filenames twice: as a 8+3 byte
strings and as a 255 unicode (UTF-16-LE) string (UTF-16-LE).
On which OS do you
On Mon, Jan 24, 2011 at 04:39:54PM +, Stefan Spoettl wrote:
So it may be that the Python interpreter isn't working correctly onlyon
Ubuntu 10.10
Than you should report the problem to the Ubuntu developers, right?
And it would be nice if you investigate deeper and send a proper mail -
Bug reports should be filed at bugs.python.org
On Mon, Jan 24, 2011 at 08:39, Stefan Spoettl spoe...@hotmail.com wrote:
Using:
Python 2.7.0+ (r27:82500, Sep 15 2010, 18:14:55)
[GCC 4.4.5] on linux2
(Ubuntu 10.10)
Method to reproduce error:
1. Defining a module which is later imported by
On Mon, Jan 24, 2011 at 07:33, Nick Coghlan ncogh...@gmail.com wrote:
On Mon, Jan 24, 2011 at 9:29 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 24 Jan 2011 20:33:07 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Mon, Jan 24, 2011 at 6:22 AM, Brett Cannon br...@python.org wrote:
In
On Mon, Jan 24, 2011 at 07:46, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 22 Jan 2011 17:08:00 -0800
Brett Cannon br...@python.org wrote:
Two, what should the final URL be? Georg picked the current one and I
am happy with it.
Ditto for me.
Three, where should it be linked from?
Looking at http://docs.python.org/dev/library/html.html#module-html it would
appear that we've created a new module with a single trivial function.
In reality, there was already a python package, html, that served to group two
loosely related modules, html.parser and html.entities.
ISTM, that
Am 24.01.2011 20:04, schrieb Raymond Hettinger:
Looking at http://docs.python.org/dev/library/html.html#module-html it would
appear that we've created a new module with a single trivial function.
In reality, there was already a python package, html, that served to group
two loosely related
Right now, the tests for the unittest package are under the package directory
instead of Lib/test where we have most of the other tests.
There are some other packages that do the same thing, each for their own reason.
I think we should develop a strong preference for tests going under Lib/test
Am 23.01.2011 02:48, schrieb Nick Coghlan:
On Sun, Jan 23, 2011 at 7:23 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Jan 22, 2011, at 11:04 AM, Terry Reedy wrote:
The 3.x docs mostly started fresh with 3.0. The major exception is the
What's new section, which goes back to
On Mon, Jan 24, 2011 at 2:04 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
ISTM, that if we're going to use python packages as namespace containers for
categorizing modules, then the top level __init__ namespace should be left
empty.
This is only an issue if the separate components
Right now, the tests for the unittest package are under the
package directory instead of Lib/test where we have most of the
other tests.
There are some other packages that do the same thing, each for
their own reason.
The corresponding bug report is #10572 (opened by Michael Foord).
R.
I have been thinking about Unicode representation for some time now.
This was triggered, on the one hand, by discussions with Glyph Lefkowitz
(who complained that his server app consumes too much memory), and Carl
Friedrich Bolz (who profiled Python applications to determine that
Unicode strings
On Mon, Jan 24, 2011 at 2:46 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
P.S. I've discussed this with Michael and his preference is against
going back to the Py3.1 style where the tests were under Lib/test. He
thinks the current tree makes it easier to sync with Py2.7 and the
Am 24.01.2011 16:39, schrieb Victor Stinner:
Le lundi 24 janvier 2011 11:35:22, Stephen J. Turnbull a écrit :
... VFAT-formatted file systems and Shift JIS file names ...
I missed something: VFAT stores filenames as unicode (whereas FAT only
supports byte filenames). Well, VFAT stores
On Jan 24, 2011, at 11:46 AM, Raymond Hettinger wrote:
P.S. I've discussed this with Michael and his preference is against going
back to the Py3.1 style where the tests were under Lib/test. He thinks the
current tree makes it easier to sync with Py2.7 and the unittest2 third-party
module.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/24/2011 03:14 PM, Fred Drake wrote:
On Mon, Jan 24, 2011 at 2:04 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
ISTM, that if we're going to use python packages as namespace containers
for
categorizing modules, then the top level
On Mon, 24 Jan 2011 11:46:45 -0800
Raymond Hettinger raymond.hettin...@gmail.com wrote:
This isn't a critical issue (nothing is broken) but we're a week from another
release candidate, so the new Py3.2 package organization (unittest was flat
in Py3.1 and its test were under Lib/test) is
On Mon, 24 Jan 2011 21:17:34 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
I have been thinking about Unicode representation for some time now.
This was triggered, on the one hand, by discussions with Glyph Lefkowitz
(who complained that his server app consumes too much memory), and Carl
2011/1/24 Éric Araujo mer...@netwok.org:
Right now, the tests for the unittest package are under the
package directory instead of Lib/test where we have most of the
other tests.
There are some other packages that do the same thing, each for
their own reason.
The corresponding bug report is
On 1/24/2011 2:18 PM, Georg Brandl wrote:
Am 24.01.2011 20:04, schrieb Raymond Hettinger:
Looking at http://docs.python.org/dev/library/html.html#module-html
it would appear that we've created a new module with a single
trivial function.
In reality, there was already a python package, html,
If that pattern is a goal, having all versions of the namespace's
__init__.py empty of anything but the __path__-munging majyk /
boilerplate is required to make such installs work regardless of the
order of PYTHONPATH.
With PEP 382, having extensible packages won't contradict to having
a
I'd like to propose PEP 393, which takes a different approach,
addressing both problems simultaneously: by getting a flexible
representation (one that can be either 1, 2, or 4 bytes), we can
support the full range of Unicode on all systems, but still use
only one byte per character for
On Mon, Jan 24, 2011 at 11:18, Georg Brandl g.bra...@gmx.net wrote:
Am 24.01.2011 20:04, schrieb Raymond Hettinger:
Looking at http://docs.python.org/dev/library/html.html#module-html it would
appear that we've created a new module with a single trivial function.
In reality, there was already
This isn't a critical issue (nothing is broken) but we're a week
from another release candidate, so the new Py3.2 package
organization (unittest was flat in Py3.1 and its test were under
Lib/test) is about to become a de-facto decision that will be hard
to undo.
Well can we stop being
Le mardi 25 janvier 2011 à 00:07 +0100, Martin v. Löwis a écrit :
I'd like to propose PEP 393, which takes a different approach,
addressing both problems simultaneously: by getting a flexible
representation (one that can be either 1, 2, or 4 bytes), we can
support the full range of Unicode
Le mardi 25 janvier 2011 à 00:14 +0100, Martin v. Löwis a écrit :
This isn't a critical issue (nothing is broken) but we're a week
from another release candidate, so the new Py3.2 package
organization (unittest was flat in Py3.1 and its test were under
Lib/test) is about to become a
On 24/01/2011 19:46, Raymond Hettinger wrote:
Right now, the tests for the unittest package are under the package directory
instead of Lib/test where we have most of the other tests.
There are some other packages that do the same thing, each for their own reason.
I think we should develop a
On 24/01/2011 23:14, Martin v. Löwis wrote:
This isn't a critical issue (nothing is broken) but we're a week
from another release candidate, so the new Py3.2 package
organization (unittest was flat in Py3.1 and its test were under
Lib/test) is about to become a de-facto decision that will be
On Mon, 2011-01-24 at 21:17 +0100, Martin v. Löwis wrote:
... snip ...
I'd like to propose PEP 393, which takes a different approach,
addressing both problems simultaneously: by getting a flexible
representation (one that can be either 1, 2, or 4 bytes), we can
support the full range of
On Jan 24, 2011, at 3:40 PM, Michael Foord wrote:
It isn't just unittest, it seems that all *test packages* are in their
respective package and not Lib/test except for the json module where Raymond
already moved the tests:
distutils/tests
email/test
ctypes/test
On Thu, Jan 20, 2011 at 03:27:08PM -0500, Glyph Lefkowitz wrote:
On Jan 20, 2011, at 11:46 AM, Guido van Rossum wrote:
Same here. *Most* code will never be shared, or will only be shared
between users in the same community. When it goes wrong it's also a
learning opportunity. :-)
On Mon, Jan 24, 2011 at 4:59 PM, Tres Seaver tsea...@palladion.com wrote:
It might matter if we want to enable third-party package installation
into a namespace also used by the stdlib: ISTR that the 'xml' package
had such installs at one point.
Almost, but not quite.
The xml package at one
Am 25.01.2011 00:14, schrieb Martin v. Löwis:
This isn't a critical issue (nothing is broken) but we're a week
from another release candidate, so the new Py3.2 package
organization (unittest was flat in Py3.1 and its test were under
Lib/test) is about to become a de-facto decision that will be
Am 25.01.2011 02:19, schrieb Raymond Hettinger:
On Jan 24, 2011, at 3:40 PM, Michael Foord wrote:
It isn't just unittest, it seems that all *test packages* are in their
respective package and not Lib/test except for the json module where Raymond
already moved the tests:
50 matches
Mail list logo
