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
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 p
On Thu, Jan 20, 2011 at 12:11 AM, Glyph Lefkowitz
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 y
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
Pytho
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 t
On Wed, Jan 19, 2011 at 11:39 PM, Toshio Kuratomi 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 shape a young
> stud
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 thi
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 non-portable
On Wed, Jan 19, 2011 at 9:07 PM, Toshio Kuratomi 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
> arbitrary encodings
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 hav
On Wed, Jan 19, 2011 at 15:49, Antoine Pitrou wrote:
> On Wed, 19 Jan 2011 15:31:24 -0800
> Brett Cannon 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 o
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 sup
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
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 latin
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 w
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 1/19/2011 6:05 PM, Alexander Belopolsky wrote:
On Wed, Jan 19, 2011 at 5:47 PM, Brett Cannon 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 lik
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 imp
On Wed, 19 Jan 2011 15:31:24 -0800
Brett Cannon 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)
> ---
> REA
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 t
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 edi
Hi,
On Wed, Jan 19, 2011 at 23:19, brett.cannon 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 time). You have a coupl
On Thu, Jan 20, 2011 at 4:40 AM, Barry Warsaw 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 been lock
On Wed, Jan 19, 2011 at 5:47 PM, Brett Cannon 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 being dire
On Wed, Jan 19, 2011 at 14:23, Alexander Belopolsky
wrote:
> On Wed, Jan 19, 2011 at 4:40 PM, Terry Reedy 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
On Wed, Jan 19, 2011 at 4:40 PM, Terry Reedy 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.
__
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 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, th
On 19/01/2011 19:47, Antoine Pitrou wrote:
On Wed, 19 Jan 2011 19:20:01 +0100
Michael Foord 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. At least mention idioms
On 1/19/2011 1:25 PM, Brett Cannon wrote:
On Wed, Jan 19, 2011 at 10:10, 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 sys
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 modul
On Wed, Jan 19, 2011 at 10:32 PM, Terry Reedy 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 ::= "import" m
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 path
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 i
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
app
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
> > 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 a
2011/1/19 Michael Foord :
> 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
On Wed, Jan 19, 2011 at 1:42 PM, Brett Cannon 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 Windows-only issues
On Wed, 19 Jan 2011 19:20:01 +0100
Michael Foord 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. At least mention idioms
> > which likely to apply across a w
On Wed, Jan 19, 2011 at 10:38, Alexander Belopolsky
wrote:
> On Wed, Jan 19, 2011 at 1:23 PM, Brett Cannon 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 sup
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
On Wed, Jan 19, 2011 at 1:23 PM, Brett Cannon 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+ ..
>>> import
On Wed, Jan 19, 2011 at 10:10, 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 would flame o
On Wed, Jan 19, 2011 at 07:01, Simon Cross
wrote:
> On Wed, Jan 19, 2011 at 2:34 PM, Victor Stinner
> 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 th
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 a
On 19/01/2011 11:35, Nick Coghlan wrote:
On Wed, Jan 19, 2011 at 5:32 AM, 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 "up
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
Pyth
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 t
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
Steven D'Aprano 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
> > equate to
>> 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 sophisticat
> 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.
___
On Thu, 20 Jan 2011 01:54:37 +1100
Steven D'Aprano 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) issue, as I un
On Wed, Jan 19, 2011 at 2:34 PM, Victor Stinner
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 the other hand, a general
Antoine Pitrou wrote:
On Thu, 20 Jan 2011 01:23:26 +1100
Steven D'Aprano 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 i
On Thu, 20 Jan 2011 01:23:26 +1100
Steven D'Aprano 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 d
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, esp
Le 17/01/2011 23:41, Nick Coghlan a écrit :
> On Tue, Jan 18, 2011 at 6:54 AM, Antoine Pitrou 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 a little
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
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 rou
On Wed, Jan 19, 2011 at 5:32 AM, 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 more of
62 matches
Mail list logo
