On Wed, Jan 19, 2011 at 5:32 AM, s...@pobox.com wrote:
The odds that someone will remember the syntax for the diff command for the
VCS are much higher than the revert command. My guess is diff is executed
more often than any other version control commands except update and
commit, and far
Nick Usually, this is because I will have edited the source tree since
Nick applying the patch. Reversion has the advantage of not getting
Nick confused by any additional changes. I also usually use svn diff
Nick to save a copy before I revert in case I change my mind.
I
Hi,
I patched Python 3.2 to support modules with non-ASCII paths (*). It
works well on all operating systems. But the task is not completly done:
(a) Python 3 doesn't support non-ASCII module names
(b) Python 3 doesn't support unencodable characters in the module path
I would like to know if
Le 17/01/2011 23:41, Nick Coghlan a écrit :
On Tue, Jan 18, 2011 at 6:54 AM, Antoine Pitrou solip...@pitrou.net wrote:
[...]
Also, I see no need to put the maintainers list in the dev guide,
actually.
Every time I see someone syncing the version-independent maintainers
list across branches
s...@pobox.com wrote:
I realize the world is passing me by and that I'm rapidly turning into a
dinosaur w.r.t. distributed version control, but as you write/update the
developer's guide remember that proficiency in Python does not necessarily
equate to proficiency in version control systems,
On Thu, 20 Jan 2011 01:23:26 +1100
Steven D'Aprano st...@pearwood.info wrote:
s...@pobox.com wrote:
I realize the world is passing me by and that I'm rapidly turning into a
dinosaur w.r.t. distributed version control, but as you write/update the
developer's guide remember that proficiency
Antoine Pitrou wrote:
On Thu, 20 Jan 2011 01:23:26 +1100
Steven D'Aprano st...@pearwood.info wrote:
s...@pobox.com wrote:
I realize the world is passing me by and that I'm rapidly turning into a
dinosaur w.r.t. distributed version control, but as you write/update the
developer's guide
On Wed, Jan 19, 2011 at 2:34 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
(a) Python 3 doesn't support non-ASCII module names
-0: I'm vaguely against this being supported because I'd rather not
have to deal with what happens when the guess regarding the filesystem
encoding is wrong.
On Thu, 20 Jan 2011 01:54:37 +1100
Steven D'Aprano st...@pearwood.info wrote:
You'll have to ask Skip if he thinks there's a concrete problem. I
haven't seen one, but I've only been reading this thread with one eye
and it may be I've missed the mother of all problems.
The (non-concrete)
Bonus question: if we remove maintainers.rst from py3k, what do we do in
3.1 and 2.7? Iâd favor removing them over keeping outdated versions.
Is there not some advantage to knowing who was the maintainer (or expert)
of a given module at the time of a release?
Eric.
What he said, only bolded and underlined.
Antoine I'm not sure what the issue is. Is there something, concretely,
Antoine that needs to be fixed?
Strictly speaking, nothing needs to be fixed because nothing is broken.
Rephrasing my earlier messages:
1. Being a sophisticated
Steven D'Aprano st...@pearwood.info wrote:
s...@pobox.com wrote:
I realize the world is passing me by and that I'm rapidly turning into a
dinosaur w.r.t. distributed version control, but as you write/update the
developer's guide remember that proficiency in Python does not necessarily
On Wed, 19 Jan 2011 10:36:04 -0600
s...@pobox.com wrote:
What he said, only bolded and underlined.
Antoine I'm not sure what the issue is. Is there something, concretely,
Antoine that needs to be fixed?
Strictly speaking, nothing needs to be fixed because nothing is broken.
Am 19.01.2011 16:25, schrieb Eric Smith:
Bonus question: if we remove maintainers.rst from py3k, what do we do in
3.1 and 2.7? I’d favor removing them over keeping outdated versions.
Is there not some advantage to knowing who was the maintainer (or expert)
of a given module at the time of
Antoine Ok, thank you but... are you suggesting something or not?
Yes. Keep the vcs command recommendations simple. At least mention idioms
which likely to apply across a wider range of version control systems.
S
___
Python-Dev mailing list
On 19/01/2011 11:35, Nick Coghlan wrote:
On Wed, Jan 19, 2011 at 5:32 AM,s...@pobox.com wrote:
The odds that someone will remember the syntax for the diff command for the
VCS are much higher than the revert command. My guess is diff is executed
more often than any other version control
On 19/01/2011 19:10, s...@pobox.com wrote:
Antoine Ok, thank you but... are you suggesting something or not?
Yes. Keep the vcs command recommendations simple. At least mention idioms
which likely to apply across a wider range of version control systems.
The revert works with svn, hg
On Wed, Jan 19, 2011 at 07:01, Simon Cross
hodgestar+python...@gmail.com wrote:
On Wed, Jan 19, 2011 at 2:34 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
(a) Python 3 doesn't support non-ASCII module names
-0: I'm vaguely against this being supported because I'd rather not
have to
On Wed, Jan 19, 2011 at 10:10, s...@pobox.com wrote:
Antoine Ok, thank you but... are you suggesting something or not?
Yes. Keep the vcs command recommendations simple. At least mention idioms
which likely to apply across a wider range of version control systems.
I was hoping this
On Wed, Jan 19, 2011 at 1:23 PM, Brett Cannon br...@python.org wrote:
..
(a) Python 3 doesn't support non-ASCII module names
..
-0 from me (unless the Unicode variable naming PEP says otherwise).
I am not sure what exactly is not supported. On my OSX system:
$ ./python.exe
Python 3.2b2+ ..
On Jan 19, 2011, at 12:16 AM, Nick Coghlan wrote:
For the release schedule PEPs it means done and dusted (similar to
the meaning for ordinary PEPs). For the API standardisation PEPs (like
WSGI) it instead means the spec has been locked down and any changes
will require a new PEP. This caused a
On Wed, Jan 19, 2011 at 10:38, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Jan 19, 2011 at 1:23 PM, Brett Cannon br...@python.org wrote:
..
(a) Python 3 doesn't support non-ASCII module names
..
-0 from me (unless the Unicode variable naming PEP says otherwise).
I
On Wed, Jan 19, 2011 at 1:42 PM, Brett Cannon br...@python.org wrote:
..
I am not sure what exactly is not supported. On my OSX system:
Victor said this is a Windows-specific issue.
I missed that part. In this case, I change my vote to +0 to reflect
my lack of knowledge or exposure to
2011/1/19 Michael Foord fuzzy...@voidspace.org.uk:
On 19/01/2011 19:10, s...@pobox.com wrote:
Antoine Ok, thank you but... are you suggesting something or not?
Yes. Keep the vcs command recommendations simple. At least mention
idioms
which likely to apply across a wider range of
The revert works with svn, hg and bzr. Using patch is not going to work on
Windoze unless cygwin has been installed.
I thought you were supposed to use some variant of update on hg
instead revert, though.
I think what is discouraged is to hg revert to a different revision.
We are talking
Le mercredi 19 janvier 2011 à 10:42 -0800, Brett Cannon a écrit :
I am not sure what exactly is not supported. On my OSX system:
Victor said this is a Windows-specific issue.
Autoquote: (a) (...) doesn't work with a locale encoding different than
UTF-8
Hum, it's not exactly the locale
On 1/19/2011 11:31 AM, Victor Stinner wrote:
If we decide to reject non-ASCII module names, it should be done on any
operating systems, not only on Windows.
Since Python allows non-ASCII variable names, I think it should allow
non-ASCII module names also, on any platform that supports the
On 1/19/2011 7:34 AM, Victor Stinner wrote:
Hi,
I patched Python 3.2 to support modules with non-ASCII paths (*). It
works well on all operating systems. But the task is not completly
done:
(a) Python 3 doesn't support non-ASCII module names (b) Python 3
doesn't support unencodable characters
Le mercredi 19 janvier 2011 à 13:38 -0500, Alexander Belopolsky a
écrit :
PEP 3131 does not distinguish between different types of identifiers,
so I think it assumes that non-ascii module names should be supported.
My opinion is that we should suport non-ASCII module names and
unencodable paths
On Wed, Jan 19, 2011 at 10:32 PM, Terry Reedy tjre...@udel.edu wrote:
I am a little shocked at the so-far tepid response to (a), so let me
defend and explain my claim that it is a bug.
In the simplest case (from 6.11. The import statement and 2.3. Identifiers
and keywords)
import_stmt ::=
Am 19.01.2011 21:32, schrieb Terry Reedy:
On 1/19/2011 7:34 AM, Victor Stinner wrote:
Hi,
I patched Python 3.2 to support modules with non-ASCII paths (*). It
works well on all operating systems. But the task is not completly
done:
(a) Python 3 doesn't support non-ASCII module names (b)
On 1/19/2011 1:25 PM, Brett Cannon wrote:
On Wed, Jan 19, 2011 at 10:10,s...@pobox.com wrote:
Antoine Ok, thank you but... are you suggesting something or not?
Yes. Keep the vcs command recommendations simple. At least mention idioms
which likely to apply across a wider range of
On 19/01/2011 19:47, Antoine Pitrou wrote:
On Wed, 19 Jan 2011 19:20:01 +0100
Michael Foordfuzzy...@voidspace.org.uk wrote:
On 19/01/2011 19:10, s...@pobox.com wrote:
Antoine Ok, thank you but... are you suggesting something or not?
Yes. Keep the vcs command recommendations simple.
On 1/19/2011 4:05 PM, Simon Cross wrote:
I have no problem with non-ASCII module identifiers being valid
syntax. It's a question of whether attempting to translate a non-ASCII
If the names are the same, ie, produced with the same sequence of
keystrokes in the save-as box and importing box,
Le mercredi 19 janvier 2011 à 12:19 -0800, Glenn Linderman a écrit :
Since Python allows non-ASCII variable names, I think it should allow
non-ASCII module names also, on any platform that supports the
appropriate characters in the filesystem.
Since some platforms already accept them,
On Wed, Jan 19, 2011 at 4:40 PM, Terry Reedy tjre...@udel.edu wrote:
..
For similar reasons we tend to avoid capital letters in module names.
That is a stdlib style guide followed by many, but intentionally not
enforced.
Indeed. Last time I looked, we still had cProfile in stdlib.
On Wed, Jan 19, 2011 at 14:23, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Jan 19, 2011 at 4:40 PM, Terry Reedy tjre...@udel.edu wrote:
..
For similar reasons we tend to avoid capital letters in module names.
That is a stdlib style guide followed by many, but
On Wed, Jan 19, 2011 at 5:47 PM, Brett Cannon br...@python.org wrote:
..
Indeed. Last time I looked, we still had cProfile in stdlib.
Yes, but that is because no one got around to hiding cProfile behind
profile before we released Python 3.0. I would still like to see it
(slowly) go away from
On Thu, Jan 20, 2011 at 4:40 AM, Barry Warsaw ba...@python.org wrote:
On Jan 19, 2011, at 12:16 AM, Nick Coghlan wrote:
For the release schedule PEPs it means done and dusted (similar to
the meaning for ordinary PEPs). For the API standardisation PEPs (like
WSGI) it instead means the spec has
Hi,
On Wed, Jan 19, 2011 at 23:19, brett.cannon python-check...@python.org wrote:
+Where to Get Help
+=
+If you are working on Python it is very possible you will come across an
issue
+where you need some assistance in solving (this happens to core developers
all
+the
OK, here is my plan that I will implement:
MOVE
--
developers.txt
maintainers.rst
README.gdb
README.coverity
README.Emacs
DELETE (seem way too old to still be relevant; tell me if I am wrong)
---
README.OpenBSD
README.AIX
cheatsheet
LEAVE everything else (with README properly
On Wed, Jan 19, 2011 at 04:40:24PM -0500, Terry Reedy wrote:
On 1/19/2011 4:05 PM, Simon Cross wrote:
I have no problem with non-ASCII module identifiers being valid
syntax. It's a question of whether attempting to translate a non-ASCII
If the names are the same, ie, produced with the same
On Wed, 19 Jan 2011 15:31:24 -0800
Brett Cannon br...@python.org wrote:
OK, here is my plan that I will implement:
MOVE
--
developers.txt
maintainers.rst
README.gdb
README.coverity
README.Emacs
DELETE (seem way too old to still be relevant; tell me if I am wrong)
---
On 1/19/2011 6:44 PM, Toshio Kuratomi wrote:
I believe we now have the situation that a package that works on *nix
could fail on Windows, whereas I believe that patch would *improve*
portability.
I'm not so sure about this
Forget that claim if it is not true. The patch will certainly
On 1/19/2011 6:05 PM, Alexander Belopolsky wrote:
On Wed, Jan 19, 2011 at 5:47 PM, Brett Cannonbr...@python.org wrote:
..
Indeed. Last time I looked, we still had cProfile in stdlib.
Yes, but that is because no one got around to hiding cProfile behind
profile before we released Python 3.0.
Le mercredi 19 janvier 2011 à 15:44 -0800, Toshio Kuratomi a écrit :
Additionally, many unix filesystem don't specify a filesystem encoding for
filenames; they deal in legal and illegal bytes which could lead to
troubles. This problem of which encoding to use is a problem that can be
seen on
On Jan 19, 2011, at 6:44 PM, Toshio Kuratomi wrote:
This problem of which encoding to use is a problem that can be
seen on UNIX systems even now. Try this:
echo 'print(hi)' café.py
convmv -f utf-8 -t latin1 café.py
python3 -c 'import café'
ASCII seems very sensible to me when faced
On Wed, Jan 19, 2011 at 07:11:52PM -0500, James Y Knight wrote:
On Jan 19, 2011, at 6:44 PM, Toshio Kuratomi wrote:
This problem of which encoding to use is a problem that can be
seen on UNIX systems even now. Try this:
echo 'print(hi)' café.py
convmv -f utf-8 -t latin1 café.py
On Thu, Jan 20, 2011 at 01:26:01AM +0100, Victor Stinner wrote:
Le mercredi 19 janvier 2011 à 15:44 -0800, Toshio Kuratomi a écrit :
Additionally, many unix filesystem don't specify a filesystem encoding for
filenames; they deal in legal and illegal bytes which could lead to
troubles.
Le mercredi 19 janvier 2011 à 18:07 -0800, Toshio Kuratomi a écrit :
Saying that multiple encodings on a single system is a misconfiguration
every time it comes up does not make it true.
Yes, each filesystem can have its own encoding. For example, this is
supported by Linux. Python doesn't
On Wed, Jan 19, 2011 at 15:49, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 19 Jan 2011 15:31:24 -0800
Brett Cannon br...@python.org wrote:
OK, here is my plan that I will implement:
MOVE
--
developers.txt
maintainers.rst
README.gdb
README.coverity
README.Emacs
DELETE
On Thu, Jan 20, 2011 at 03:51:05AM +0100, Victor Stinner wrote:
For a lesson at school, it is nice to write examples in the
mother language, instead of using raw english with ASCII identifiers
and filenames.
Then use this::
import cafe as café
When you do things this way you do not have to
On Wed, Jan 19, 2011 at 9:07 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
..
Do you have a solution to the problem? I haven't looked at your patch so
perhaps you have an ingenous method of translating from the unicode
representation of the module in the import statement to the bytes in
On 1/19/2011 8:39 PM, Toshio Kuratomi wrote:
use this::
import cafe as café
When you do things this way you do not have to translate between unknown
encodings into unicode. Everything is within python source where you have
a defined encoding.
This is a great way of converting
On Jan 20, 2011, at 12:02 AM, Glenn Linderman wrote:
But for local code, having to think up an ASCII name for a module rather than
use the obvious native-language name, is just brain-burden when creating the
code.
Is it really? You already had to type 'import', presumably if you can think
On Wed, Jan 19, 2011 at 11:39 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
..
Teaching students to write non-portable code (relying on filesystem encoding
where your solution is, don't upload to pypi anything that has non-ascii
filenames) seems like the exact opposite of how you'd want to
On 1/19/2011 9:11 PM, Glyph Lefkowitz wrote:
On Jan 20, 2011, at 12:02 AM, Glenn Linderman wrote:
But for local code, having to think up an ASCII name for a module
rather than use the obvious native-language name, is just
brain-burden when creating the code.
Is it really? You already had
On Jan 20, 2011, at 12:19 AM, Glenn Linderman wrote:
Now if the stuff after m_ was the hex UTF-8 of café, that could get
interesting :)
(As it happens, it's the hex digest of the MD5 of the UTF-8 of café... ;-))___
Python-Dev mailing list
On Thu, Jan 20, 2011 at 12:11 AM, Glyph Lefkowitz
gl...@twistedmatrix.com wrote:
..
But for local code, having to think up an ASCII name for a module rather
than use the obvious native-language name, is just brain-burden when
creating the code.
Is it really? You already had to type 'import',
On Wed, Jan 19, 2011 at 09:02:17PM -0800, Glenn Linderman wrote:
On 1/19/2011 8:39 PM, Toshio Kuratomi wrote:
use this::
import cafe as café
When you do things this way you do not have to translate between unknown
encodings into unicode. Everything is within python
On 1/19/2011 11:20 PM, Toshio Kuratomi wrote:
On Wed, Jan 19, 2011 at 09:02:17PM -0800, Glenn Linderman wrote:
On 1/19/2011 8:39 PM, Toshio Kuratomi wrote:
use this::
import cafe as café
When you do things this way you do not have to translate between unknown
encodings
61 matches
Mail list logo
