Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[Ron Adam]

Martin v. Löwis wrote:
>> This is what prompted my question, actually: in Py3k, in the
>> str/unicode unification branch, r"\u1234" changes meaning: before the
>> unification, this was an 8-bit string, where the \u was not special,
>> but now it is a unicode string, where \u *is* special.
> 
> That is true for non-raw strings also: the meaning of "\u1234" also
> changes.
> 
> However, traditionally, there was *no* escaping mechanism in raw strings
> in Python, and I feel that this is a good principle, because it is
> easy to learn (if you leave out the detail that \ can't be the last
> character in a raw string - which should get fixed also, IMO). So I
> think in Py3k, "\u1234" should continue to be a string with 6
> characters. Otherwise, people will complain that
> os.stat(r"c:\windows\system32\user32.dll") fails. Telling them to write
> os.stat(r"c:\windows\system32\u005Cuser32.dll") will just cause puzzled
> faces.
> 
> Windows path names are one of the two primary applications of raw
> strings (the other being regexes).


I think regular expressions become easier to read if they don't also 
contain python escape characters because then you don't have to mentally 
parse which ones are part of the regular expression and which ones are 
evaluated by python.  The re module can still evaluate r"\u", r"\'", 
and r'\"' sequences even if python doesn't.

I experimented with tokanize.c to see if the trailing '\' could be special 
cased in raw strings.  The minimum change I could come up with was to have 
it not respect slash-quote sequences, (for finding the end of a string), if 
the quote is the same type as the quote used to define the string.  The 
following strings in the library needed to be adjusted after that change.

I don't think this is the best solution, but the list of strings needing 
changed might be useful for the discussion.


-r'(\'[^\']*\'|"[^"]*"|[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*))?')
+r'''(\'[^\']*\'|"[^"]*"|[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*))?''')


-_declstringlit_match = re.compile(r'(\'[^\']*\'|"[^"]*")\s*').match
+_declstringlit_match = re.compile(r'''(\'[^\']*\'|"[^"]*")\s*''').match


-r'(?<=[\w\!\"\'\&\.\,\?])-{2,}(?=\w))')   # em-dash
+r'''(?<=[\w\!\"\'\&\.\,\?])-{2,}(?=\w))''')   # em-dash


- r'[\"\']?'   # optional end-of-quote
+ r'''[\"\']?'''   # optional 
end-of-quote


-_wordchars_re = re.compile(r'[^\\\'\"%s ]*' % string.whitespace)
+_wordchars_re = re.compile(r'''[^\\\'\"%s ]*''' % string.whitespace)


-HEADER_QUOTED_VALUE_RE = re.compile(r"^\s*=\s*\"([^\"\\]*(?:\\.[^\"\\]*)*)\"")
+HEADER_QUOTED_VALUE_RE = 
re.compile(r'''^\s*=\s*\"([^\"\\]*(?:\\.[^\"\\]*)*)\"''')

-HEADER_JOIN_ESCAPE_RE = re.compile(r"([\"\\])")
+HEADER_JOIN_ESCAPE_RE = re.compile(r'([\"\\])')

-quote_re = re.compile(r"([\"\\])")
+quote_re = re.compile(r'([\"\\])')


-return re.sub(r'((\\[\\abfnrtv\'"]|\\[0-9]..|\\x..|\\u)+)',
+return re.sub(r'''((\\[\\abfnrtv\'"]|\\[0-9]..|\\x..|\\u)+)''',


-_OPTION_DIRECTIVE_RE = re.compile(r'#\s*doctest:\s*([^\n\'"]*)$',
+_OPTION_DIRECTIVE_RE = re.compile(r'''#\s*doctest:\s*([^\n\'"]*)$''',
re.MULTILINE)


-s = unicode(r'\x00="\'a\\b\x80\xff\u\u0001\u1234', 
'unicode-escape')
+s = unicode(r'''\x00="\'a\\b\x80\xff\u\u0001\u1234''', d


-_escape = re.compile(r"[&<>\"\x80-\xff]+") # 1.5.2
+_escape = re.compile(r'[&<>\"\x80-\xff]+') # 1.5.2


-r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)[EMAIL PROTECTED]))?')
+r'''(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)[EMAIL PROTECTED]))?''')



I also noticed that python handles the '\' escape character differently 
than re does in regular strings.  In regular expressions, a single '\' is 
always an escape character.  If the following character is not a special 
character, then the two character combination becomes the second 
non-special character.

 "\'"  --> '
 "\\"  --> \
 "\q"  --> q  ('q' not special so '\q' is 'q')

This isn't how python does it.

 >>> '\''
"'"
 >>> "\\"
'\\'
 >>> "\q"('q' not special, so Back slash is not an escape.)
'\q'


So it might be good to have it always be an escape in regular strings, and 
never be an escape in raw strings.

Ron

___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[M.-A. Lemburg]

On 2007-05-11 07:52, Martin v. Löwis wrote:
>> This is what prompted my question, actually: in Py3k, in the
>> str/unicode unification branch, r"\u1234" changes meaning: before the
>> unification, this was an 8-bit string, where the \u was not special,
>> but now it is a unicode string, where \u *is* special.
> 
> That is true for non-raw strings also: the meaning of "\u1234" also
> changes.
> 
> However, traditionally, there was *no* escaping mechanism in raw strings
> in Python, and I feel that this is a good principle, because it is
> easy to learn (if you leave out the detail that \ can't be the last
> character in a raw string - which should get fixed also, IMO). So I
> think in Py3k, "\u1234" should continue to be a string with 6
> characters. Otherwise, people will complain that
> os.stat(r"c:\windows\system32\user32.dll") fails. Telling them to write
> os.stat(r"c:\windows\system32\u005Cuser32.dll") will just cause puzzled
> faces.

Using double backslashes won't cause that reaction:

os.stat("c:\\windows\\system32\\user32.dll")

Also note that Windows is smart enough nowadays to parse
the good old Unix forward slash:

os.stat("c:/windows/system32/user32.dll")

> Windows path names are one of the two primary applications of raw
> strings (the other being regexes).

IMHO the primary use case are regexps and for those you'd
definitely want to be able to put Unicode characters into your
expressions.

BTW, if you use ur"..." for your expressions today (which you should
if you parse text), then nothing will change when removing the
'u' prefix in Py3k.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 11 2007)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[Georg Brandl]

M.-A. Lemburg schrieb:

>> Windows path names are one of the two primary applications of raw
>> strings (the other being regexes).
> 
> IMHO the primary use case are regexps and for those you'd
> definitely want to be able to put Unicode characters into your
> expressions.

Except if sre_parse would recognize \u and \U escapes, just like it
does now with \x escapes.

Georg

___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[M.-A. Lemburg]

On 2007-05-11 13:05, Thomas Heller wrote:
> M.-A. Lemburg schrieb:
>> On 2007-05-11 07:52, Martin v. Löwis wrote:
 This is what prompted my question, actually: in Py3k, in the
 str/unicode unification branch, r"\u1234" changes meaning: before the
 unification, this was an 8-bit string, where the \u was not special,
 but now it is a unicode string, where \u *is* special.
>>> That is true for non-raw strings also: the meaning of "\u1234" also
>>> changes.
>>>
>>> However, traditionally, there was *no* escaping mechanism in raw strings
>>> in Python, and I feel that this is a good principle, because it is
>>> easy to learn (if you leave out the detail that \ can't be the last
>>> character in a raw string - which should get fixed also, IMO). So I
>>> think in Py3k, "\u1234" should continue to be a string with 6
>>> characters. Otherwise, people will complain that
>>> os.stat(r"c:\windows\system32\user32.dll") fails. Telling them to write
>>> os.stat(r"c:\windows\system32\u005Cuser32.dll") will just cause puzzled
>>> faces.
>> Using double backslashes won't cause that reaction:
>>
>> os.stat("c:\\windows\\system32\\user32.dll")
> 
> Sure.  But I want to use raw strings for Windows path names; it's much easier
> to type.

But think of the price to pay if we disable use of Unicode
escapes in raw strings. And all of this just because of the
one special case: having a file name that starts with a U
and needs to be referenced literally in a Python application
together with a path leading up to it.

BTW, there's an easy work-around for this special case:

os.stat(os.path.join(r"c:\windows\system32", "user32.dll"))

>> Also note that Windows is smart enough nowadays to parse
>> the good old Unix forward slash:
>>
>> os.stat("c:/windows/system32/user32.dll")
> 
> In my opinion this is a windows bug and not a features.  Especially because 
> there
> are Windows api functions (the shell functions, IIRC) that do NOT accept
> forward slashes.
> 
> Would you say that *nix is dumb because it doesn't parse "\\usr\\include"?

Sorry, I wasn't trying to imply that Windows is/was a dumb system.

I think it's nice that you can use forward slashes on Windows -
makes writing code that works in both worlds (Unix and Windows)
a lot easier.

>>> Windows path names are one of the two primary applications of raw
>>> strings (the other being regexes).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 11 2007)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[Thomas Heller]

M.-A. Lemburg schrieb:
> On 2007-05-11 07:52, Martin v. Löwis wrote:
>>> This is what prompted my question, actually: in Py3k, in the
>>> str/unicode unification branch, r"\u1234" changes meaning: before the
>>> unification, this was an 8-bit string, where the \u was not special,
>>> but now it is a unicode string, where \u *is* special.
>> 
>> That is true for non-raw strings also: the meaning of "\u1234" also
>> changes.
>> 
>> However, traditionally, there was *no* escaping mechanism in raw strings
>> in Python, and I feel that this is a good principle, because it is
>> easy to learn (if you leave out the detail that \ can't be the last
>> character in a raw string - which should get fixed also, IMO). So I
>> think in Py3k, "\u1234" should continue to be a string with 6
>> characters. Otherwise, people will complain that
>> os.stat(r"c:\windows\system32\user32.dll") fails. Telling them to write
>> os.stat(r"c:\windows\system32\u005Cuser32.dll") will just cause puzzled
>> faces.
> 
> Using double backslashes won't cause that reaction:
> 
> os.stat("c:\\windows\\system32\\user32.dll")

Sure.  But I want to use raw strings for Windows path names; it's much easier
to type.

> Also note that Windows is smart enough nowadays to parse
> the good old Unix forward slash:
> 
> os.stat("c:/windows/system32/user32.dll")

In my opinion this is a windows bug and not a features.  Especially because 
there
are Windows api functions (the shell functions, IIRC) that do NOT accept
forward slashes.

Would you say that *nix is dumb because it doesn't parse "\\usr\\include"?

>> Windows path names are one of the two primary applications of raw
>> strings (the other being regexes).
> 

Thomas

___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[Guido van Rossum]

On 5/10/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Windows path names are one of the two primary applications of raw
> strings (the other being regexes).

I disagree with this use case; the r"..." notation was not invented
for this purpose. I won't compromise the escaping of quotes to
accommodate it. Nevertheless I think that \u and \U should lose their
special-ness in 3.0.

I'd like to hear from anyone who has access to *real code* that uses
\u or \U in a raw unicode string.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[David Goodger]

Guido van Rossum  python.org> writes:
> I'd like to hear from anyone who has access to *real code* that uses
> \u or \U in a raw unicode string.

Docutils uses it in the docutils.parsers.rst.states module, Body class:

patterns = {
  'bullet': ur'[-+*\u2022\u2023\u2043]( +|$)',
...

attribution_pattern = re.compile(ur'(---?(?!-)|\u2014) *(?=[^ \n])')

-- David Goodger 

___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[Guido van Rossum]

On 5/11/07, David Goodger <[EMAIL PROTECTED]> wrote:
> Guido van Rossum  python.org> writes:
> > I'd like to hear from anyone who has access to *real code* that uses
> > \u or \U in a raw unicode string.
>
> Docutils uses it in the docutils.parsers.rst.states module, Body class:
>
> patterns = {
>   'bullet': ur'[-+*\u2022\u2023\u2043]( +|$)',
> ...
>
> attribution_pattern = re.compile(ur'(---?(?!-)|\u2014) *(?=[^ \n])')

But wouldn't it be just as handy to teach the re module about \u and
\U, just as it already knows about \x (and \123 octals)?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[David Goodger]

> Guido van Rossum  python.org> writes:
> > I'd like to hear from anyone who has access to *real code* that uses
> > \u or \U in a raw unicode string.

David Goodger  python.org> writes:
> Docutils uses it in the docutils.parsers.rst.states module, Body class:
> 
> patterns = {
>   'bullet': ur'[-+*\u2022\u2023\u2043]( +|$)',
> ...
> 
> attribution_pattern = re.compile(ur'(---?(?!-)|\u2014) *(?=[^ \n])')

Although admittedly, these don't *have* to be raw strings, since they don't
contain backslashes as regexp syntax.  They were made raw by reflex, because
they contain regular expressions.

-- DG

___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[David Goodger]

> On 5/11/07, David Goodger <[EMAIL PROTECTED]> wrote:
> > Docutils uses it in the docutils.parsers.rst.states module, Body class:
> >
> > patterns = {
> >   'bullet': ur'[-+*\u2022\u2023\u2043]( +|$)',
> > ...
> >
> > attribution_pattern = re.compile(ur'(---?(?!-)|\u2014) *(?=[^ \n])')

On 5/11/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> But wouldn't it be just as handy to teach the re module about \u and
> \U, just as it already knows about \x (and \123 octals)?

Could be. I'm just providing examples, as requested.
I leave the heavy thinking to others ;-)

-- 
David Goodger 
___
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-archive.com

Re: [Python-Dev] Official version support statement

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 10, 2007, at 12:53 PM, Terry Reedy wrote:

> This strikes me as a bit over-officious (the 'officially' adds  
> nothing to
> me except a bit of stuffiness).
>
> Worse, it seems wrong and hence, to me, misleading.  The current de  
> facto
> policy is that when a new major release comes out, there is a *final*
> minor, bugfix release of the previous major version.  Thus, 2.5 is  
> being
> supported while 2.6 is being worked on.  As I understand it, there  
> are no
> more plans to touch 2.4 than 2.3 and so on.  So the current message  
> is:
> "If you want a 2.5 bug fixed, find it, report it, and help get it  
> fixed now
> before 2.6 is released."
>
> I am aware that if a trustworthy person or persons were to backport  
> some
> substantial numbers of fixes from 2.5 to 2.4, greenlight the test  
> suite on
> several systems, cut release candidates, and repond to reports, the  
> file
> would appear on the official Python site.  But currently, as far as  
> I know,
> this 'support' is as empty as the Official Help-Yourself Plate of  
> Donated
> Cookies on my kitchen table.

I'm happy to document whatever we decide the policy is, but I think  
we should decide and produce an official statement as such.  It helps  
users and vendors to know what they can count on us for and what they  
might be on their own for.  It's also not that big of a deal if we  
amend the policy later because we have volunteer release managers for  
earlier versions.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRkTp43EjvBPtnXfVAQJCigP9GtmkyIpI7NadM0pfPIIsLkLCvqFA8sNe
oMVv5cGMtkDaw6x4kuITv+EL0CCXopXgz89vTq1bFrrmBbJpR1Bk3ToB9L2VvWPl
kjxzExIwaS8xtywfw7j5Mn2vfBVpK7lewL5POwOg9QQ1r51cHcTjoL/28FD1yqf2
5rUahZFDTLY=
=xQjh
-END PGP SIGNATURE-
___
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-archive.com

Re: [Python-Dev] Official version support statement

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 10, 2007, at 6:46 PM, Martin v. Löwis wrote:

>> "The Python Software Foundation officially supports the current
>> stable major release and one prior major release.  Currently, Python
>> 2.5 and 2.4 are officially supported.
>
> If you take "officially supported" to mean "there will be further  
> bugfix
> releases", then no: 2.4 is not anymore officially supported. Only 2.5
> is officially supported. There may, of course, be security patches
> released for 2.4 if there is a need.

Is this draft any better?

"The Python Software Foundation officially supports the current  
stable major release of Python.  By "supports" we mean that the PSF  
will produce bug fix releases of this version, currently Python 2.5.   
We may release patches for earlier versions if necessary, such as to  
fix security problems, but we generally do not make releases of such  
unsupported versions.  Patch releases of earlier Python versions may  
be made available through third parties, including OS vendors."

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRkTraHEjvBPtnXfVAQLsZAP/eOCIn77Z+wfbdX0ys8N1LWCd242alW/p
6ws9qa6BQ2At5tDBAZtwjR2QX8LKn4zlM2CgaqvVrEjvZ8hgtSDv4hC0jfa0YCHQ
bUrNzu3pZfJm62S0SFs753jtcImRFwBMBHHBU47N6GqXOB+mAlMgvAtch3Zakidq
37by4Iefj84=
=28A4
-END PGP SIGNATURE-
___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[Michael Foord]

Martin v. Löwis wrote:
>> This is what prompted my question, actually: in Py3k, in the
>> str/unicode unification branch, r"\u1234" changes meaning: before the
>> unification, this was an 8-bit string, where the \u was not special,
>> but now it is a unicode string, where \u *is* special.
>> 
>
> That is true for non-raw strings also: the meaning of "\u1234" also
> changes.
>
> However, traditionally, there was *no* escaping mechanism in raw strings
> in Python, and I feel that this is a good principle, because it is
> easy to learn (if you leave out the detail that \ can't be the last
> character in a raw string - which should get fixed also, IMO).
+1

Michael Foord
___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[Martin v. Löwis]

> Using double backslashes won't cause that reaction:
> 
> os.stat("c:\\windows\\system32\\user32.dll")

Please refer to the subject. We are talking about raw strings.

>> Windows path names are one of the two primary applications of raw
>> strings (the other being regexes).
> 
> IMHO the primary use case are regexps

It's not a matter of opinion. It's a statistical fact that these
are the two cases where people use raw strings most.

> and for those you'd
> definitely want to be able to put Unicode characters into your
> expressions.

For regular expressions, you don't need them as part of the
string literal syntax: The re parser itself could support \u,
just like it supports \x today.

> BTW, if you use ur"..." for your expressions today (which you should
> if you parse text), then nothing will change when removing the
> 'u' prefix in Py3k.

How do you know? Py3k hasn't been released, yet.

Regards,
Martin

___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[Martin v. Löwis]

> BTW, there's an easy work-around for this special case:
> 
> os.stat(os.path.join(r"c:\windows\system32", "user32.dll"))

No matter what the decision is, there are always work-arounds.
The question is what language suits the users most. Being
able to specify characters by ordinal IMO has much less value
than the a consistent, concise definition of raw strings has.

> I think it's nice that you can use forward slashes on Windows -
> makes writing code that works in both worlds (Unix and Windows)
> a lot easier.

But, as Thomas says: you can't. You may be able to do so
when using the API directly, however, it fails if you
pass the file name in a command line of some tool that
takes /foo to mean a command line option "foo".

Regards.
Martin

___
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-archive.com

Re: [Python-Dev] Official version support statement

[Martin v. Löwis]

> "The Python Software Foundation officially supports the current  
> stable major release of Python.  By "supports" we mean that the PSF  
> will produce bug fix releases of this version, currently Python 2.5.   
> We may release patches for earlier versions if necessary, such as to  
> fix security problems, but we generally do not make releases of such  
> unsupported versions.  Patch releases of earlier Python versions may  
> be made available through third parties, including OS vendors."

If such an official statement still can be superseded by an even more
official PEP, it's fine with me.

However, I would prefer to not use the verb "support" at all. We (the
PSF) don't provide any technical support for *any* version ever
released: '''PSF is making Python available to Licensee on an "AS IS"
basis.  PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
IMPLIED.  BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT
INFRINGE ANY THIRD PARTY RIGHTS.'''

The more I think about it: no, there is no official support for the
current stable release. We will like produce more bug fix releases,
but then, we may not if the volunteers doing so lose time or
interest, and 2.6 comes out earlier than planned.

Why do you need such a statement?

Regards,
Martin
___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[Guido van Rossum]

I think I'm going to break my own rules and ask Martin to write up a
PEP. Given the pragmatics that Windows pathnames *are* a common use
case, I'm willing to let allow the trailing \ in the string. A regular
expression containing a quote could be written using triple quotes,
e.g. r"""(["'])[^"']*\1""". (A single " in a regular expression can
always be rewritten as ["] AFAIK.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[M.-A. Lemburg]

On 2007-05-12 00:48, Martin v. Löwis wrote:
>> Using double backslashes won't cause that reaction:
>>
>> os.stat("c:\\windows\\system32\\user32.dll")
> 
> Please refer to the subject. We are talking about raw strings.

If you'd leave the context in place, the reason for my suggestion
would become evident.

>>> Windows path names are one of the two primary applications of raw
>>> strings (the other being regexes).
>> IMHO the primary use case are regexps
> 
> It's not a matter of opinion. It's a statistical fact that these
> are the two cases where people use raw strings most.

Ah, statistics :-) It always depends on who you ask: a Windows
user will obviously have more use for raw string use-case you
gave than a Unix user. At the end of the day, I still believe
that the regexp use-case is by far more common than the Windows
path name one.

FWIW: Zope has 2 uses of raw string for Windows path names (if I
counted correctly) and around 100 for regexps. Python itself
has maybe 10-20 Windows path name (and registry name) uses of
raw string (in the msi lib and distutils) vs. around 300 uses
for regexps.

>> and for those you'd
>> definitely want to be able to put Unicode characters into your
>> expressions.
> 
> For regular expressions, you don't need them as part of the
> string literal syntax: The re parser itself could support \u,
> just like it supports \x today.

True and perhaps that's the right path to follow.

You'd still have the problem of writing Windows path names with
embedded Unicode characters, but I guess that's something we
can fix another day ;-)

>> BTW, if you use ur"..." for your expressions today (which you should
>> if you parse text), then nothing will change when removing the
>> 'u' prefix in Py3k.
> 
> How do you know? Py3k hasn't been released, yet.

Sorry, I wasn't clear: if the raw-unicode-escape codec continues
to work the way it does not, you won't run into trouble in Py3k.

[and later:]
>> BTW, there's an easy work-around for this special case:
>> > 
>> > os.stat(os.path.join(r"c:\windows\system32", "user32.dll"))
> 
> No matter what the decision is, there are always work-arounds.
> The question is what language suits the users most. Being
> able to specify characters by ordinal IMO has much less value
> than the a consistent, concise definition of raw strings has.

I wonder how we managed to survive all these years with
the existing consistent and concise definition of the
raw-unicode-escape codec ;-)

There are two options:

 * no one really uses Unicode raw strings nowadays

 * none of the existing users has ever stumbled across the
   "problem case" that triggered all this

Both ways, we're discussing a non-issue.

>> > I think it's nice that you can use forward slashes on Windows -
>> > makes writing code that works in both worlds (Unix and Windows)
>> > a lot easier.
> 
> But, as Thomas says: you can't. You may be able to do so
> when using the API directly, however, it fails if you
> pass the file name in a command line of some tool that
> takes /foo to mean a command line option "foo".

Strange. I've doing exactly that for years. Maybe it's just
because I stick to common os module APIs. So far, I've never
run into any problem with it.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 12 2007)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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-archive.com

Re: [Python-Dev] New operations in Decimal

[Greg Ewing]

Terry Reedy wrote:

> "Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message 

> | While I question the sanity of the spec writers in this case, I do trust 
> that
> | overall, they have provided an extremely well thought-out spec, have gone
> | through extensive discussion/feedback cycles, and have provided a 
> thorough
> | test-suite.  It is as good as it gets.
> 
> I had the same opinion until I saw the logic stuff.

The only rationale I can think of for such a thing is
that maybe they're trying to accommodate the possibility
of a machine built entirely around a hardware implementation
of the spec, that doesn't have any other way of doing
bitwise logical operations.

If that's the case, then Python clearly has no need
for it.

--
Greg
___
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-archive.com

Re: [Python-Dev] New operations in Decimal

[Raymond Hettinger]

> The only rationale I can think of for such a thing is
> that maybe they're trying to accommodate the possibility
> of a machine built entirely around a hardware implementation
> of the spec, that doesn't have any other way of doing
> bitwise logical operations.  If that's the case, then Python
> clearly has no need for it.

Doesn't matter.  My intention for the module is to be fully compliant with the 
spec and all of its tests.  Code written in other languages which support the 
spec should expect to be transferrable to Python and run exactly as they did in 
the original language.  

The module itself makes that promise:

"this module should be kept in sync with the latest updates
of the IBM specification as it evolves.  Those updates will 
be treated as bug fixes (deviation from the spec is considered
a compatibility, usability bug)"

If I still have any say in the matter, please consider this a pronouncement.  
Tim, if you're listening, please chime in.


Raymond
___
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-archive.com

Re: [Python-Dev] New operations in Decimal

[Nick Coghlan]

Greg Ewing wrote:
> Terry Reedy wrote:
>> I had the same opinion until I saw the logic stuff.
> 
> The only rationale I can think of for such a thing is
> that maybe they're trying to accommodate the possibility
> of a machine built entirely around a hardware implementation
> of the spec, that doesn't have any other way of doing
> bitwise logical operations.
> 
> If that's the case, then Python clearly has no need
> for it.

That is my interpretation of the spec as well. I'd prefer to see a 
decimal.BitSequence subtype added to the module rather than lumping the 
functionality into the main decimal.Decimal type.

The specification itself makes it clear that these operations are not 
supported for the full range of decimal numbers:

"The logical operations (and, invert, or, and xor) take logical 
operands, which are finite numbers with a sign of 0, an exponent of 0, 
and a coefficient whose digits must all be either 0 or 1."

The footnote attached to the quoted sentence also makes it clear that 
this is about still being able to do binary logic operations with a 
purely decimal ALU:

"This digit-wise representation of bits in a decimal representation has 
been used since the 1950s; see, for example, Binary and truth-function 
operations on a decimal computer with an extract command, William H. 
Kautz, Communications of the ACM, Vol. 1 #5, pp12-13, ACM Press, May 1958."

Regards,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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-archive.com

Re: [Python-Dev] \u and \U escapes in raw unicode string literals

[Andrew McNabb]

On Sat, May 12, 2007 at 01:30:52AM +0200, M.-A. Lemburg wrote:
> 
> I wonder how we managed to survive all these years with
> the existing consistent and concise definition of the
> raw-unicode-escape codec ;-)
> 
> There are two options:
> 
>  * no one really uses Unicode raw strings nowadays
> 
>  * none of the existing users has ever stumbled across the
>"problem case" that triggered all this
> 
> Both ways, we're discussing a non-issue.


Sure, it's a non-issue for Python 2.x.  However, when Python 3 comes
along, and all strings are Unicode, there will likely be a lot more
users stumbling into the problem case.

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868


pgpBqD8o8hnO1.pgp
Description: PGP signature
___
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-archive.com

Re: [Python-Dev] Official version support statement

[Tony Nelson]

At 12:58 AM +0200 5/12/07, Martin v. Löwis wrote:
>> "The Python Software Foundation officially supports the current
>> stable major release of Python.  By "supports" we mean that the PSF
>> will produce bug fix releases of this version, currently Python 2.5.
>> We may release patches for earlier versions if necessary, such as to
>> fix security problems, but we generally do not make releases of such
>> unsupported versions.  Patch releases of earlier Python versions may
>> be made available through third parties, including OS vendors."
>
>If such an official statement still can be superseded by an even more
>official PEP, it's fine with me.
>
>However, I would prefer to not use the verb "support" at all. We (the
>PSF) don't provide any technical support for *any* version ever
>released: '''PSF is making Python available to Licensee on an "AS IS"
>basis.  PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
>IMPLIED.  BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND
>DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
>FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT
>INFRINGE ANY THIRD PARTY RIGHTS.'''
>
>The more I think about it: no, there is no official support for the
>current stable release. We will like produce more bug fix releases,
>but then, we may not if the volunteers doing so lose time or
>interest, and 2.6 comes out earlier than planned.
>
>Why do you need such a statement?

I think Fedora might want it, per recent discussions on fedora-devel-list.

My impertinent attempt:

"The Python Software Foundation maintains the current stable major
release of Python.  By "maintains" we mean that the PSF will produce
bug fix releases of that version, currently Python 2.5.  We have
released patches for earlier versions as necessary, such as to fix
security problems, but we generally do not make releases of such
prior versions.  Patched releases of earlier Python versions may be
made available through third parties, including OS vendors."
-- 

TonyN.:'   
  '  
___
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-archive.com

Re: [Python-Dev] Official version support statement

[skip]

Tony> "The Python Software Foundation maintains the current stable major
Tony> release of Python.  By "maintains" we mean that the PSF will
Tony> produce bug fix releases of that version, currently Python 2.5.
Tony> We have released patches for earlier versions as necessary, such
Tony> as to fix security problems, but we generally do not make releases
Tony> of such prior versions.  Patched releases of earlier Python
Tony> versions may be made available through third parties, including OS
Tony> vendors."

Since there is (generally?) an attempt to make one last bug fix release of
the previous version after the next major version is released, should that
be mentioned?  To make it concrete, I believe shortly after 2.5.0 was
released the final bug fix release of 2.4 (2.4.4?) was released.

Skip
___
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-archive.com

Re: [Python-Dev] Official version support statement

[Terry Reedy]

"Tony Nelson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

At 12:58 AM +0200 5/12/07, Martin v. Löwis wrote:
|>However, I would prefer to not use the verb "support" at all.

agreed

|"The Python Software Foundation maintains the current stable major
|release of Python.  By "maintains" we mean that the PSF will produce
|bug fix releases of that version, currently Python 2.5.

This strikes me as an improvement, but 'maintain' is close to 'support' and 
seems to make a promise that might also have unintended legal consequences. 
But that is what your legal consel is for.

The actuality is that the legal fiction called the PSF *releases* new 
versions produced by a collection of volunteers, some of whom are PSF 
members and who perhaps consider that they do their work 'in the name of' 
PSF, and some of whom are not PSF members and perhaps do not have such a 
consideration.

Defining CPython as a PSF rather than volunteer community product might 
discourage volunteer contributions.  'Official' statements need both 
motivation (what is there that is actually broken?) and care (to not break 
something else).

| We have released patches for earlier versions as necessary, such as to 
fix
security problems,

Funny thing here is that the security releases, by necessity, are more a 
PSF product than normal releases.

Terry Jan Reedy



___
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-archive.com

Re: [Python-Dev] New operations in Decimal

[Terry Reedy]

"Greg Ewing" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| The only rationale I can think of for such a thing is
| that maybe they're trying to accommodate the possibility
| of a machine built entirely around a hardware implementation
| of the spec, that doesn't have any other way of doing
| bitwise logical operations.

That is what I meant by 'commercial strategy' in my previous post.  The IBM 
site pages mentioned the possibility of a decimal-based processor back when 
I read it, which was back when the decimal module was being developed.  It 
would fit both their decades of product history and their name (*business 
machines*).  Nothing nefarious, exactly, ..

| If that's the case, then Python clearly has no need for it.

but think it should at least be discussed whether to add useless functions 
while somewhat useful functions are being deleted and other useful 
functions are being denied entry.

Terry Jan Reedy



___
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-archive.com

Re: [Python-Dev] Official version support statement

[Stephen J. Turnbull]

"Martin v. Löwis" writes:

 > However, I would prefer to not use the verb "support" at all. We (the
 > PSF) don't provide any technical support for *any* version ever
 > released: '''PSF is making Python available to Licensee on an "AS IS"
 > basis.  PSF MAKES NO REPRESENTATIONS OR WARRANTIES [...].'''

Of course the PSF provides *excellent* technical support; you just
don't acknowledge any *obligation* to do it.  A declaration of support
is not a warranty, of course.  So I see no problem with using the word
"support".  You may wish to clarify with terms like "resources
available".

 > Why do you need such a statement?

Because it expresses what IMO *actually happens* clearly, and
clarifies the intent of the PSF to continue in the same way.  This is
useful to users making decisions, even though the PSF owns few to none
of the resources needed.  The generosity of the contributors and their
loyalty to Python and to each other practically guarantees availability.

Python can dispose of a raft of bugs present only in the older
versions with WONTFIX at release of a new stable version (after
double-checking that they don't exist in the stable version).
Developers can respond to reports of bugs in the immediate past
version with "I'm sorry, but we try to concentrate our limited
resources on supporting the current version, and it is unlikely that
it will be fixed.  Please post to c.l.p for help."  Users are
disappointed, but it builds trust, and more so if supported by an
official statement.
___
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-archive.com

Re: [Python-Dev] New operations in Decimal

[Raymond Hettinger]

> The only rationale I can think of for such a thing is
> that maybe they're trying to accommodate the possibility
> of a machine built entirely around a hardware implementation
> of the spec, that doesn't have any other way of doing
> bitwise logical operations.

Nonsense.  The logical operations are there for environments where decimal is 
the only available numeric type.
IIRC, this is how Rexx works with decimal implemented around strings where what 
you type is what you get.


Raymond
___
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-archive.com

Re: [Python-Dev] New operations in Decimal

[Tim Peters]

[Raymond Hettinger]
> ...
> My intention for the module is to be fully compliant with the spec and all of 
> its
> tests.  Code written in other languages which support the spec should expect
> to be transferrable to Python and run exactly as they did in the original 
> language.
>
> The module itself makes that promise:
>
> "this module should be kept in sync with the latest updates
> of the IBM specification as it evolves.  Those updates will
> be treated as bug fixes (deviation from the spec is considered
> a compatibility, usability bug)"
>
> If I still have any say in the matter, please consider this a pronouncement.  
> Tim,
> if you're listening, please chime in.

That was one of the major goals in agreeing to adopt an external
standard for decimal:  tedious arguments are left to the standard
creators instead of clogging python-dev.  Glad to see that's working
exactly as planned ;-)

I'm with Raymond on this one, especially given the triviality of
implementing the revised spec's new logical operations.

I personally wish they would have added more transcendental functions
to the spec instead.  That's bread-and-butter stuff for FP
applications, while I don't see much use for the new "bit" operations.
 But if I felt strongly enough about that, I'd direct my concerns to
the folks creating this standard.  As slippery slopes go, this less
than a handful of trivial new operations isn't steep enough to
measure, let alone cause a landslide.
___
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-archive.com

Re: [Python-Dev] Official version support statement

[Anthony Baxter]

On Saturday 12 May 2007, [EMAIL PROTECTED] wrote:
> Since there is (generally?) an attempt to make one last bug fix
> release of the previous version after the next major version is
> released, should that be mentioned?  To make it concrete, I
> believe shortly after 2.5.0 was released the final bug fix
> release of 2.4 (2.4.4?) was released.

Correct. Note that this is only something that's been in place while 
I've been doing it. The current "standard" for how we do releases 
is just something I made up as I went along, including 
- regular 6-monthly bugfix releases
- only one maintenance branch (most recent) for the bugfix releases
- the last bugfix release of the previous release after a new major 
release.

I'm OK with these being formalised - but any additional requirements 
I'd like to discuss first :-)

Anthony

-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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-archive.com