Re: [Python-Dev] len(chr(i)) = 2?

[Martin v. Löwis]

> Unicode 5.0, Chapter 3, verse C9:
> 
> When a process generates a code unit sequence which purports to be
> in a Unicode character encoding form, it shall not emit ill-formed
> code sequences.

>  > > A Unicode-conforming Python implementation would error at the
>  > > chr() call, or perhaps would not provide surrogateescape error
>  > > handlers.
>  > 
>  > Chapter and verse?
> 
> Chapter 3, verse C9 again.

I agree that the surrogateescape error handler is non-conforming, but,
as you say, it doesn't claim to, either (would your concern about utf-8
being misleading here been resolved if the thing had been called
"utf-8b"?)

More interestingly (and to the subject) is chr: how did you arrive
at C9 banning Python3's definition of chr? This chr function puts
the code sequence into well-formed UTF-16; that's the whole point of
UTF-16.

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] len(chr(i)) = 2?

[Stephen J. Turnbull]

"Martin v. Löwis" writes:

 > More interestingly (and to the subject) is chr: how did you arrive
 > at C9 banning Python3's definition of chr? This chr function puts
 > the code sequence into well-formed UTF-16; that's the whole point of
 > UTF-16.

No, it doesn't, in the specific case of surrogate code points.  In
3.1.2 from MacPorts on a iBook G4 and from Gentoo on AMD64,
chr(0xd800) returns "\ud800".

I don't know if that's by design (eg, so that it can be used in the
implementation of the surrogateescape error handler) or a correctable
oversight, but it's not conformant.


___
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] len(chr(i)) = 2?

[Stephen J. Turnbull]

Raymond Hettinger writes:

 > Neither UTF-16 nor UCS-2 is exactly correct anyway.

>From a standards lawyer point of view, UCS-2 is exactly correct, as
far as I can tell upon rereading ISO 10646-1, especially Annexes H
("retransmitting devices") and Q ("UTF-16").  Annex Q makes it clear
that UTF-16 was intentionally designed so that Python-style processing
could be done in a UCS-2 context.

 > For the "wide" build, the entire range of unicode is encoded at
 > 4 bytes per character and slicing/len operate correctly since
 > every character is the same length.   This used to be called UCS-4
 > and is now UTF-32.

That's inaccurate, I believe.  UCS-4 is not a UTF, and doesn't satisfy
the range restrictions of a UTF.

 > So, with "wide" builds there isn't much confusion (except perhaps
 > unfamiliar terminology).   The real issue seems to be that for 
 > "narrow" builds, none of the usual encoding names is exactly
 > correct.  

I disagree.  I do see a problem with "UCS-2", because it fails to tell
us that Python implements a large number of features that make it easy
to do a very good job of working with non-BMP data in 16-bit builds of
Python, with no extra effort.  Python is not perfect, and (rarely)
some of the imperfections may be very distressing.  But it's very
good, and deserves to be advertised as such.

However, I don't see how "narrow" tells us more than "UCS-2" does.  If
"UCS-2" is equally (or more) informative, I prefer it because it is
the technically precise, already well-defined, term.

 > From a users point-of-view, the actual encoding or encoding name 
 > doesn't matter much.  They just need to be able to predict the relevant
 > behaviors (memory consumption and len/slicing behavior).

"UCS-2" indicates those behaviors precisely and concisely.  The
problems are (a) the lack of familiarity of users with this term, if
David is reasonably representative, and (b) the fact that it fails to
advertise Python's UTF-16 capabilities.  "Narrow" suffers from both of
those problems, and further from the fact that it has no independent
standard definition.  Furthermore, "wide" has a very widespread,
platform-dependent meaning derived from wchar_t.

If we have to document what the terms we choose mean anyway, why not
document the existing terms and reduce entropy, rather than invent new
ones and increase entropy?

___
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] len(chr(i)) = 2?

[Martin v. Löwis]

Am 22.11.2010 11:47, schrieb Stephen J. Turnbull:
> "Martin v. Löwis" writes:
> 
>  > More interestingly (and to the subject) is chr: how did you arrive
>  > at C9 banning Python3's definition of chr? This chr function puts
>  > the code sequence into well-formed UTF-16; that's the whole point of
>  > UTF-16.
> 
> No, it doesn't, in the specific case of surrogate code points.  In
> 3.1.2 from MacPorts on a iBook G4 and from Gentoo on AMD64,
> chr(0xd800) returns "\ud800".

Ah, I see - this is *not* the subject's issue, right?

> 
> I don't know if that's by design (eg, so that it can be used in the
> implementation of the surrogateescape error handler) or a correctable
> oversight, but it's not conformant.

I disagree: Quoting from Unicode 5.0, section 5.4:

# The individual components of implementations may have different
# levels of support for surrogates, as long as those components are
# assembled and communicate correctly. Low-level string processing,
# where a Unicode string is not interpreted but is handled simply as an
# array of code units, may ignore surrogate pairs. With such strings,
# for example, a truncation operation with an arbitrary offset might
# break a surrogate pair. (For further discussion, see Section 2.7,
# Unicode Strings.) For performance in string operations, such behavior
# is reasonable at a low level, but it requires higher-level processes
# to ensure that offsets are on character boundaries so as to guarantee
# the integrity of surrogate pairs.

So lower-level routines (which I claim chr() is one) are allowed
to create lone surrogates. The formal requirement behind this is C1:

# A process shall not interpret a high-surrogate code point or a
# low-surrogate code point as an abstract character.

I also claim that Python, in both narrow and wide mode, conforms to
this requirement. Notice that the requirement is a ban on interpreting
the code point as a character. In particular, unicodedata.category
claims that the code point is of class Cs (surrogate), which I consider
conforming.

By the same line of reasoning, it is also OK that chr() allows the
creation of unassigned code points, even though C2 says that they
must not be interpreted as abstract characters.

The rationale for supporting these characters in chr() goes back much
further than the surrogateescape handler - as Python unicode strings
are sequences of code points, it would be impractical if you couldn't
create some of them, or even would have to consult the UCD before
determining whether they can be created.

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] len(chr(i)) = 2?

[Martin v. Löwis]

Am 22.11.2010 11:48, schrieb Stephen J. Turnbull:
> Raymond Hettinger writes:
> 
>  > Neither UTF-16 nor UCS-2 is exactly correct anyway.
> 
>>From a standards lawyer point of view, UCS-2 is exactly correct, as
> far as I can tell upon rereading ISO 10646-1, especially Annexes H
> ("retransmitting devices") and Q ("UTF-16").  Annex Q makes it clear
> that UTF-16 was intentionally designed so that Python-style processing
> could be done in a UCS-2 context.

I could only find the FCD of 10646:2010, where annex H was integrated
into section 10:

http://www.itscj.ipsj.or.jp/sc2/open/02n4125/FCD10646-Main.pdf

There they have stopped using the term UCS-2, and added a note

# NOTE – Former editions of this standard included references to a
# two-octet BMP form called UCS-2 which would be a subset
# of the UTF-16 encoding form restricted to the BMP UCS scalar values. #
The UCS-2 form is deprecated.

I think they are now acknowledging that UCS-2 was a misleading term,
making it ambiguous whether this refers to a CCS, a CEF, or a CES;
like "ASCII", people have been using it for all three of them.

Apparently, the ISO WG interprets earlier revisions as saying that
UCS-2 is a CEF that restricted UTF-16 to the BMP. THIS IS NOT WHAT
PYTHON DOES. In a narrow Python build, the character set is *not*
restricted to the BMP. Instead, Unicode strings are meant to be
interpreted (by applications) as UTF-16.

>  > For the "wide" build, the entire range of unicode is encoded at
>  > 4 bytes per character and slicing/len operate correctly since
>  > every character is the same length.   This used to be called UCS-4
>  > and is now UTF-32.
> 
> That's inaccurate, I believe.  UCS-4 is not a UTF, and doesn't satisfy
> the range restrictions of a UTF.

Not sure what it says in your copy; in mine, section 9.3 says

# 9.3 UTF-32 (UCS-4)
# UTF-32 (or UCS-4) is the UCS encoding form that assigns each UCS
# scalar value to a single unsigned 32-bit code unit. The terms UTF-32 #
and UCS-4 can be used interchangeably to designate this encoding
# form.

so they (now) view the two as synonyms.

I think that when ISO 10646 started, they were also fairly confused
about these issues (as the group/plane/row/cell structure demonstrates,
IMO). This is not surprising, since the notion of byte-based character
sets had been ingrained for so long. It took 20 years to learn that
a UCS scalar value really is *not* a sequence of bytes, but a natural
number.

> However, I don't see how "narrow" tells us more than "UCS-2" does.  If
> "UCS-2" is equally (or more) informative, I prefer it because it is
> the technically precise, already well-defined, term.

But it's not. It is a confusing term, one that the relevant standards
bodies are abandoning. After reading FCD 10646:2010, I could agree to
call the two implementations UTF-16 and UTF-32 (as these terms
designate CEFs). Unfortunately, they also designate CESs.

> If we have to document what the terms we choose mean anyway, why not
> document the existing terms and reduce entropy, rather than invent new
> ones and increase entropy?

Because the proposed existing term is deprecated.

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] len(chr(i)) = 2?

[M.-A. Lemburg]

Martin,

it is really irrelevant whether the standards have decided
to no longer use the terms UCS-2 and UCS-4 in their latest
standard documents.

The definitions still stand (just like Unicode 2.0 is still a valid
standard, even if it's ten years old):

* UCS-2 is defined as "Universal Character Set coded in 2 octets"
by ISO 10464: (see http://www.unicode.org/versions/Unicode5.2.0/appC.pdf)

* UCS-4 is defined as "Universal Character Set coded in 4 octets"
by ISO 10464.

Those two terms have been in use for many years. They refer to
the Unicode character set as it can be represented in 2 or 4
bytes. As such they don't include any of the special meanings
associated with the UTF transfer encodings. There are no invalid
sequences, no invalid code points, etc. as you can find in the UTF
encodings. And that's an important detail.

If you interpret them as encodings, they are 1-1 mappings of
Unicode code point ordinals to integers represented using
2 or 4 bytes.

UCS-2 only supports BMP code points and can conveniently
be interpreted as UTF-16, if you need to encode non-BMP
code points (which we do in the UTF codecs).

UCS-4 also supports non-BMP code points directly.

Now, from a ISO or Unicode Consortium point of view, deprecating
the term UCS-2 in *their* standard papers is only natural, since
they are actively starting to assign non-BMP code points which
cannot be represented in UCS-2.

However, this deprecation is only relevant for the purpose of defining
the standard. The above definitions are still useful
when it comes to defining code units, i.e. the used storage format,
(as opposed to the transfer format).

For the purpose of describing the code units we are using in Python
they are (still) the most correct terms and that's also the reason
why we chose to use them when introducing the configure options
in Python2.

There are no other accurate definitions we could use. The terms
"narrow" and "wide" are simply too inaccurate to be used as
description of UCS-2 and UCS-4 code units.

Please also note that we have used the terms UCS-2 and UCS-4 in Python2
for 9+ years now and users are just starting to learn the difference
and get acquainted with the fact that Python uses these two forms.

Confronting them with "narrow" and "wide" builds is only
going to cause more confusion, not less, and adding those
strings to Python package files isn't going to help much either,
since the terms don't convey any relationship to Unicode:

package-3.1.3.linux-x86_64-py2.6_ucs2.egg
vs.
package-3.1.3.linux-x86_64-py2.6_narrow.egg

I opt for switching to the following config options:

--with-unicode=ucs2 (default)
--with-unicode=ucs4

and using "UCS-2" and "UCS-4" in the Python documentation when
describing the two different build modes.  We can add glossary
entries for the two which clarify the differences.

Python2 used --enable-unicode=ucs2/ucs4, but since Python3 doesn't
build without Unicode support, the above two versions appear more
appropriate.

We can keep the alternative --with-wide-unicode as an alias
for --with-unicode=ucs4 to maintain 3.x backwards compatibility.

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 22 2010)
>>> 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 our new mxODBC.Connect Python Database Interface 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
   http://www.egenix.com/company/contact/


"Martin v. Löwis" wrote:
> Am 22.11.2010 11:48, schrieb Stephen J. Turnbull:
>> Raymond Hettinger writes:
>>
>>  > Neither UTF-16 nor UCS-2 is exactly correct anyway.
>>
>> >From a standards lawyer point of view, UCS-2 is exactly correct, as
>> far as I can tell upon rereading ISO 10646-1, especially Annexes H
>> ("retransmitting devices") and Q ("UTF-16").  Annex Q makes it clear
>> that UTF-16 was intentionally designed so that Python-style processing
>> could be done in a UCS-2 context.
> 
> I could only find the FCD of 10646:2010, where annex H was integrated
> into section 10:
> 
> http://www.itscj.ipsj.or.jp/sc2/open/02n4125/FCD10646-Main.pdf
> 
> There they have stopped using the term UCS-2, and added a note
> 
> # NOTE – Former editions of this standard included references to a
> # two-octet BMP form called UCS-2 which would be a subset
> # of the UTF-16 encoding form restricted to the BMP UCS scalar values. #
> The UCS-2 form is deprecated.
> 
> I think they are now acknowledging that UCS-2 was a misleading term,
> making it ambiguous whether this refers to a CCS, a CEF, or a CES;
> like "ASCII", people have been using i

Re: [Python-Dev] len(chr(i)) = 2?

[James Y Knight]

Why don't ya'll just call them "--unichar-width=16/32". That describes 
precisely what the options do, and doesn't invite any quibbling over 
definitions.

James

___
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] [Python-checkins] r86633 - in python/branches/py3k: Doc/library/inspect.rst Doc/whatsnew/3.2.rst Lib/inspect.py Lib/test/test_inspect.py Misc/NEWS

[Nick Coghlan]

On Mon, Nov 22, 2010 at 10:54 AM, Éric Araujo  wrote:
>> +.. function:: getgeneratorstate(generator)
>> +
>> +    Get current state of a generator-iterator.
>> +
>> +    Possible states are:
>> +      GEN_CREATED: Waiting to start execution.
>> +      GEN_RUNNING: Currently being executed by the interpreter.
>> +      GEN_SUSPENDED: Currently suspended at a yield expression.
>> +      GEN_CLOSED: Execution has completed.
>
> I wonder if those shouldn’t be marked up as :data: or something to make
> them indexed.

The same definitions are in the docstrings, and they're just integer
constants so I'm not sure why anyone would be looking them up
directly. Still, if someone with greater Sphinx-fu thinks additional
markup would be helpful, I have no problem with them adding it :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] [Python-checkins] r86633 - in python/branches/py3k: Doc/library/inspect.rst Doc/whatsnew/3.2.rst Lib/inspect.py Lib/test/test_inspect.py Misc/NEWS

[Michael Foord]

On 22/11/2010 15:14, Nick Coghlan wrote:

On Mon, Nov 22, 2010 at 10:54 AM, Éric Araujo  wrote:

+.. function:: getgeneratorstate(generator)
+
+Get current state of a generator-iterator.
+
+Possible states are:
+  GEN_CREATED: Waiting to start execution.
+  GEN_RUNNING: Currently being executed by the interpreter.
+  GEN_SUSPENDED: Currently suspended at a yield expression.
+  GEN_CLOSED: Execution has completed.

I wonder if those shouldn’t be marked up as :data: or something to make
them indexed.

The same definitions are in the docstrings, and they're just integer
constants so I'm not sure why anyone would be looking them up
directly. Still, if someone with greater Sphinx-fu thinks additional
markup would be helpful, I have no problem with them adding it :)



Why not use string constants instead? You lose comparability (less than 
/ greater than) but gain readability. Comparability may be a requirement 
- of course if Python had an Enum type we could use that and have both.


Michael

Cheers,
Nick.




--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] len(chr(i)) = 2?

[Nick Coghlan]

On Mon, Nov 22, 2010 at 10:47 PM, M.-A. Lemburg  wrote:
> Please also note that we have used the terms UCS-2 and UCS-4 in Python2
> for 9+ years now and users are just starting to learn the difference
> and get acquainted with the fact that Python uses these two forms.
>
> Confronting them with "narrow" and "wide" builds is only
> going to cause more confusion, not less, and adding those
> strings to Python package files isn't going to help much either,
> since the terms don't convey any relationship to Unicode:

I was personally surprised to learn in this discussion that there had
even been an *attempt* to change the names of the two build variants
to anything other than UCS2/UCS4. The concrete API implementations
certainly still use those two terms to prevent inadvertent linkage
with the wrong version of the C API.

For practical purposes, UCS2/UCS4 convey far more inherent information
than narrow/wide:
- many developers will recognise them as Unicode related, even if they
don't know exactly what they mean
- even those that don't recognise them, can soon learn that they're
Unicode related just by plugging them into Google*
- a bit more digging should reveal that they're Unicode storage
formats closely related to the UTF-16 and UTF-32 transfer encodings
respectively*

*(The first Google hit for "ucs2" is the UTF-16/UCS-2 article on
Wikipedia, the first hit for "ucs4" is the UTF-32/UCS-4 article)

All that just armed with Google, without even looking at the Python
docs specifically.

So don't just think about "what will developers know?", also think
about "what will developers know, and what will a quick trip to a
search engine tell them?". And once you take that stance, the overly
generic narrow/wide terms fail, badly.

+1 for MAL's suggested tweaks to the Py3k configure options.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] [Python-checkins] r86633 - in python/branches/py3k: Doc/library/inspect.rst Doc/whatsnew/3.2.rst Lib/inspect.py Lib/test/test_inspect.py Misc/NEWS

[Antoine Pitrou]

On Mon, 22 Nov 2010 15:19:04 +
Michael Foord  wrote:

> On 22/11/2010 15:14, Nick Coghlan wrote:
> > On Mon, Nov 22, 2010 at 10:54 AM, Éric Araujo  wrote:
> >>> +.. function:: getgeneratorstate(generator)
> >>> +
> >>> +Get current state of a generator-iterator.
> >>> +
> >>> +Possible states are:
> >>> +  GEN_CREATED: Waiting to start execution.
> >>> +  GEN_RUNNING: Currently being executed by the interpreter.
> >>> +  GEN_SUSPENDED: Currently suspended at a yield expression.
> >>> +  GEN_CLOSED: Execution has completed.
> >> I wonder if those shouldn’t be marked up as :data: or something to make
> >> them indexed.
> > The same definitions are in the docstrings, and they're just integer
> > constants so I'm not sure why anyone would be looking them up
> > directly. Still, if someone with greater Sphinx-fu thinks additional
> > markup would be helpful, I have no problem with them adding it :)
> >
> 
> Why not use string constants instead? You lose comparability (less than 
> / greater than) but gain readability. Comparability may be a requirement 
> - of course if Python had an Enum type we could use that and have both.

+1.  The problem with int constants is that the int gets printed, not
the name, when you dump them for debugging purposes :)

cheers

Antoine.


___
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] [Python-checkins] r86633 - in python/branches/py3k: Doc/library/inspect.rst Doc/whatsnew/3.2.rst Lib/inspect.py Lib/test/test_inspect.py Misc/NEWS

[Nick Coghlan]

On Tue, Nov 23, 2010 at 1:19 AM, Michael Foord
 wrote:
> On 22/11/2010 15:14, Nick Coghlan wrote:
>> On Mon, Nov 22, 2010 at 10:54 AM, Éric Araujo  wrote:
 +    Possible states are:
 +      GEN_CREATED: Waiting to start execution.
 +      GEN_RUNNING: Currently being executed by the interpreter.
 +      GEN_SUSPENDED: Currently suspended at a yield expression.
 +      GEN_CLOSED: Execution has completed.
>>>
>>> I wonder if those shouldn’t be marked up as :data: or something to make
>>> them indexed.
>>
>> The same definitions are in the docstrings, and they're just integer
>> constants so I'm not sure why anyone would be looking them up
>> directly. Still, if someone with greater Sphinx-fu thinks additional
>> markup would be helpful, I have no problem with them adding it :)
>>
>
> Why not use string constants instead? You lose comparability (less than /
> greater than) but gain readability. Comparability may be a requirement - of
> course if Python had an Enum type we could use that and have both.

With only 4 states, comparability isn't really necessary. I'm just so
used to using the range() trick as a replacement for the lack of
proper Enum type that using strings instead didn't even occur to me.

The lack of printability did bother me a bit, so yeah, +1 from me as
well (I've reopened the relevant issue to remind me to change it
before beta 1).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] len(chr(i)) = 2?

[Alexander Belopolsky]

On Mon, Nov 22, 2010 at 10:37 AM, Nick Coghlan  wrote:
..
> *(The first Google hit for "ucs2" is the UTF-16/UCS-2 article on
> Wikipedia, the first hit for "ucs4" is the UTF-32/UCS-4 article)
>

Do you think these articles are helpful for someone learning how to
use chr() and ord() in Python for the first time?
___
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] [Python-checkins] r86633 - in python/branches/py3k: Doc/library/inspect.rst Doc/whatsnew/3.2.rst Lib/inspect.py Lib/test/test_inspect.py Misc/NEWS

[Hrvoje Niksic]

On 11/22/2010 04:37 PM, Antoine Pitrou wrote:

+1.  The problem with int constants is that the int gets printed, not
the name, when you dump them for debugging purposes :)


Well, it's trivial to subclass int to something with a nicer __repr__. 
PyGTK uses that technique for wrapping C enums:


>>> gtk.PREVIEW_GRAYSCALE

>>> isinstance(gtk.PREVIEW_GRAYSCALE, int)
True
>>> gtk.PREVIEW_GRAYSCALE + 0
1
___
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] len(chr(i)) = 2?

[Nick Coghlan]

On Tue, Nov 23, 2010 at 2:03 AM, Alexander Belopolsky
 wrote:
> On Mon, Nov 22, 2010 at 10:37 AM, Nick Coghlan  wrote:
> ..
>> *(The first Google hit for "ucs2" is the UTF-16/UCS-2 article on
>> Wikipedia, the first hit for "ucs4" is the UTF-32/UCS-4 article)
>>
>
> Do you think these articles are helpful for someone learning how to
> use chr() and ord() in Python for the first time?

No, that's what the documentation of chr() and ord() is for. For that
use case, it doesn't matter *what* the terms are. They could say "in a
FOO build this will do X, in a BAR build it will do Y, see  for
a detailed explanation of the differences between FOO and BAR builds
of Python" and be perfectly adequate for the task. If there is no
appropriate documentation link to point to (probably somewhere in the
C API docs if it isn't anywhere else) then that is a key issue that
needs to be fixed, rather than trying to change the terms that have
been in use for the better part of a decade already.

The raw meaning of UCS2/UCS4 mainly comes into the story when people
are encountering this as a config option when building Python. The
whole idea of changing the terms for the two build types *should* have
been short circuited by the "status quo wins a stalemate" guideline,
but apparently that didn't happen at the time.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] [Python-checkins] r86633 - in python/branches/py3k: Doc/library/inspect.rst Doc/whatsnew/3.2.rst Lib/inspect.py Lib/test/test_inspect.py Misc/NEWS

[Antoine Pitrou]

On Mon, 22 Nov 2010 17:08:36 +0100
Hrvoje Niksic  wrote:
> On 11/22/2010 04:37 PM, Antoine Pitrou wrote:
> > +1.  The problem with int constants is that the int gets printed, not
> > the name, when you dump them for debugging purposes :)
> 
> Well, it's trivial to subclass int to something with a nicer __repr__. 
> PyGTK uses that technique for wrapping C enums:

Nice. It might be useful to add a private _Constant class somewhere for
stdlib purposes.

Regards

Antoine.


___
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] is this a bug? no environment variables

[Guido van Rossum]

On Sun, Nov 21, 2010 at 9:40 PM, Glenn Linderman  wrote:
> In reviewing my notes from my experimentations with CGIHTTPServer
> (Python2.6) and then http.server (Python 3.2a4), I note one behavior I
> haven't reported as a bug, nor do I know where to start to figure it out,
> other than experimentally.
>
> The experiment: launching CGIHTTPServer without environment variables, by
> the simple expedient of using a batch file to unset all the existing
> environment variables, and then launching Python2.6 with CGIHTTPServer.
>
> So it failed early: random.py fails at line 110 (Python 2.6).

What specific traceback do you get? In my copy of the code that line says

a = long(_hexlify(_urandom(16)), 16)

and I could just imagine that _urandom() fails for some reason to do
with the environment (it is a reference to os.urandom()), which, being
part of the C library code, might depend on the environment.

But you're not giving enough info to debug this.

> I suppose it is possible that some environment variables are used by Python
> directly (but I can't seem to find a documented list of them) although I
> would expect that usage to be optional, with fall-back defaults when they
> don't exist.

That is certainly the idea, but the fallbacks may not always be nice.

Environment variables used by Python or the stdlib itself are supposed
to be named PYTHON if they are Python-specific, and there's
a way to disable all of these (-E). But there are other environment
variables (HOME and PATH come to mind) that have a broader definition
and that are used in some part of the stdlib. Plus, as I mentioned,
who knows what the non-Python C library uses (well, somebody probably
knows, but I don't know of a central source that we can actually trust
across the many platforms where Python runs).

> I suppose it is even possible that some Windows APIs might
> depend on some environment variables, but I expected that the registry had
> replaced such usage completely, by now, with the environment variables
> mostly being a convenience tool for batch files, or for optional, temporary
> alteration of particular settings.

That sounds like wishful thinking. :-)

> If anyone knows of documentation listing what environment variables are
> required by Python on Windows, I would appreciate a pointer, searches and
> doc browsing having not turned it up.
>
> I'll attempt to recreate the test situation later this week with Python
> 3.2a4, if no one responds, but the only debug technique I can think of is to
> slowly remove environment variables until I find the minimum set required to
> run http.server successfully for my tests with CGI files.

-- 
--Guido van Rossum (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] [Python-checkins] r86633 - in python/branches/py3k: Doc/library/inspect.rst Doc/whatsnew/3.2.rst Lib/inspect.py Lib/test/test_inspect.py Misc/NEWS

[Michael Foord]

On 22/11/2010 16:24, Antoine Pitrou wrote:

On Mon, 22 Nov 2010 17:08:36 +0100
Hrvoje Niksic  wrote:

On 11/22/2010 04:37 PM, Antoine Pitrou wrote:

+1.  The problem with int constants is that the int gets printed, not
the name, when you dump them for debugging purposes :)

Well, it's trivial to subclass int to something with a nicer __repr__.
PyGTK uses that technique for wrapping C enums:

Nice. It might be useful to add a private _Constant class somewhere for
stdlib purposes.
Why not just solve the problem properly and add it to the standard 
library... (Allowing for flag enums too that can be or'd together and 
still have a decent repr.)


Michael


Regards

Antoine.


___
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/fuzzyman%40voidspace.org.uk



--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] len(chr(i)) = 2?

[Alexander Belopolsky]

On Mon, Nov 22, 2010 at 11:13 AM, Nick Coghlan  wrote:
..
>> Do you think these articles are helpful for someone learning how to
>> use chr() and ord() in Python for the first time?
>
> No, that's what the documentation of chr() and ord() is for. For that
> use case, it doesn't matter *what* the terms are.

I recently updated  chr() and ord()  documentation and used
"narrow/wide" terms.  I thought USC2/4 proponents objected to that on
the basis that these terms are imprecise.

http://docs.python.org/dev/library/functions.html#chr
http://docs.python.org/dev/library/functions.html#ord

> They could say "in a
> FOO build this will do X, in a BAR build it will do Y, see  for
> a detailed explanation of the differences between FOO and BAR builds
> of Python" and be perfectly adequate for the task. If there is no
> appropriate documentation link to point to (probably somewhere in the
> C API docs if it isn't anywhere else) then that is a key issue that
> needs to be fixed, rather than trying to change the terms that have
> been in use for the better part of a decade already.
>

That's the point that I was trying to make.  Using somewhat vague
narrow/wide terms gives us an opportunity to describe exactly what is
going on without confusing the reader with the intricacies of the
Unicode Standard or Python'd compliance with a particular version of
it.

> The raw meaning of UCS2/UCS4 mainly comes into the story when people
> are encountering this as a config option when building Python. The
> whole idea of changing the terms for the two build types *should* have
> been short circuited by the "status quo wins a stalemate" guideline,
> but apparently that didn't happen at the time.
>

It also comes in the "Data model" reference section on String which is
currently out of date:

"""
Strings
The items of a string object are Unicode code units. A Unicode code
unit is represented by a string object of one item and can hold either
a 16-bit or 32-bit value representing a Unicode ordinal (the maximum
value for the ordinal is given in sys.maxunicode, and depends on how
Python is configured at compile time). Surrogate pairs may be present
in the Unicode object, and will be reported as two separate items. The
built-in functions chr() and ord() convert between code units and
nonnegative integers representing the Unicode ordinals as defined in
the Unicode Standard 3.0. Conversion from and to other encodings are
possible through the string method encode().
""" http://docs.python.org/dev/reference/datamodel.html

The out of date part is the reference to the Unicode Standard 3.0.  I
don't think we should refer to a specific version of Unicode here.  It
has little consequence for the "Python data model" and AFAICT does not
come into play anywhere except unicodedata which is currently at
version 6.0.

The description of chr() and ord() is also not accurate on narrow
builds and nether is the statement "The items of a string object are
Unicode code units."
___
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] [Python-checkins] r86633 - in python/branches/py3k: Doc/library/inspect.rst Doc/whatsnew/3.2.rst Lib/inspect.py Lib/test/test_inspect.py Misc/NEWS

[exarkun]

On 04:24 pm, solip...@pitrou.net wrote:

On Mon, 22 Nov 2010 17:08:36 +0100
Hrvoje Niksic  wrote:

On 11/22/2010 04:37 PM, Antoine Pitrou wrote:
> +1.  The problem with int constants is that the int gets printed, 
not

> the name, when you dump them for debugging purposes :)

Well, it's trivial to subclass int to something with a nicer __repr__.
PyGTK uses that technique for wrapping C enums:


Nice. It might be useful to add a private _Constant class somewhere for
stdlib purposes.


http://www.python.org/dev/peps/pep-0354/

Regards

Antoine.


___
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/exarkun%40twistedmatrix.com

___
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

[Python-Dev] Re-enable warnings in regrtest and/or unittest

[Ezio Melotti]

I would like to re-enable by default warnings for regrtest and/or unittest.

The reasons are:
  1) these tools are used mainly by developers and they (should) care 
about warnings;
  2) developers won't have to remember that warning are silenced and 
how to enable them manually;
  3) developers won't have to enable them manually every time they run 
the tests;
  4) some developers are not even aware that warnings have been 
silenced and might not notice things like DeprecationWarnings until the 
function/method/class/etc gets removed and breaks their code;
  5) another developer tool -- the --with-pydebug flag -- already 
re-enables warnings when it's used;


If this is fixed in unittest it won't be necessary to patch regrtest.
If it's fixed in regrtest only the core developers will benefit from this.

This could be fixed checking if any warning flags (-Wx) are passed to 
python.
If no flags are passed the default will be -Wd, otherwise the behavior 
will be the one specified by the flag.

This will allow developers to use `python -Wi` to ignore errors explicitly.

Best Regards,
Ezio Melotti
___
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] len(chr(i)) = 2?

[R. David Murray]

On Mon, 22 Nov 2010 12:00:14 -0500, Alexander Belopolsky 
 wrote:
> I recently updated  chr() and ord()  documentation and used
> "narrow/wide" terms.  I thought USC2/4 proponents objected to that on
> the basis that these terms are imprecise.

For reference, a grep in py3k/Doc reveals that there are currently exactly
23 lines mentioning UCS2 or UCS4 in the docs.  Most are in the unicode part
of the c-api, and 6 are in what's new for 2.2:

c-api/arg.rst:  Convert a null-terminated buffer of Unicode (UCS-2 or 
UCS-4) data to a Python
c-api/arg.rst:  Convert a Unicode (UCS-2 or UCS-4) data buffer and its 
length to a Python

c-api/unicode.rst:   for :c:type:`Py_UNICODE` and store Unicode values 
internally as UCS2. It is also
c-api/unicode.rst:   possible to build a UCS4 version of Python (most recent 
Linux distributions come
c-api/unicode.rst:   with UCS4 builds of Python). These builds then use a 
32-bit type for
c-api/unicode.rst:   :c:type:`Py_UNICODE` and store Unicode data internally as 
UCS4. On platforms
c-api/unicode.rst:   short` (UCS2) or :c:type:`unsigned long` (UCS4).
c-api/unicode.rst:Note that UCS2 and UCS4 Python builds are not binary 
compatible. Please keep
c-api/unicode.rst:   values is interpreted as an UCS-2 character.

whatsnew/2.2.rst:usually stored as UCS-2, as 16-bit unsigned integers. Python 
2.2 can also be
whatsnew/2.2.rst:compiled to use UCS-4, 32-bit unsigned integers, as its 
internal encoding by
whatsnew/2.2.rst:supplying :option:`--enable-unicode=ucs4` to the configure 
script.   (It's also
whatsnew/2.2.rst:When built to use UCS-4 (a "wide Python"), the interpreter can 
natively handle
whatsnew/2.2.rst:compiled to use UCS-2 (a "narrow Python"), values greater than 
65535 will still
whatsnew/2.2.rst:Marc-André Lemburg.  The changes to support using UCS-4 
internally were

howto/unicode.rst:.. comment Additional topic: building Python w/ UCS2 or UCS4 
support
howto/unicode.rst:   - [ ] Building Python (UCS2, UCS4)

library/sys.rst:   characters are stored as UCS-2 or UCS-4.

library/json.rst:   specified.  Encodings that are not ASCII based (such as 
UCS-2) are not

faq/extending.rst:When importing module X, why do I get "undefined symbol: 
PyUnicodeUCS2*"?
faq/extending.rst:If instead the name of the undefined symbol starts with 
``PyUnicodeUCS4``, the
faq/extending.rst:   ... print('UCS4 build')
faq/extending.rst:   ... print('UCS2 build')

--
R. David Murray  www.bitdance.com
___
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] Re-enable warnings in regrtest and/or unittest

[Łukasz Langa]

Am 22.11.2010 18:14, schrieb Ezio Melotti:
I would like to re-enable by default warnings for regrtest and/or 
unittest.


+1

Especially in regrtest it could help manage stdlib quality (currently we 
have a horde of ResourceWarnings, zipfile mostly). I would even be +1 on 
making warnings errors for regrtest but that seems to be unpopular on 
#python-dev.


Best regards,
Łukasz Langa
___
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] len(chr(i)) = 2?

[Alexander Belopolsky]

On Mon, Nov 22, 2010 at 12:30 PM, R. David Murray  wrote:
..
> For reference, a grep in py3k/Doc reveals that there are currently exactly
> 23 lines mentioning UCS2 or UCS4 in the docs.

Did you grep for USC-2 and USC-4 as well?  I have to admit that my
aversion to these terms is mostly due to the fact that I don't know
how to spell them correctly. :-)
___
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] len(chr(i)) = 2?

[Terry Reedy]

On 11/22/2010 5:48 AM, Stephen J. Turnbull wrote:


I disagree.  I do see a problem with "UCS-2", because it fails to tell
us that Python implements a large number of features that make it easy
to do a very good job of working with non-BMP data in 16-bit builds of


Yes. As I read the standard, UCS-2 is limited to BMP chars. So I was a 
bit confused when Python was described as UCS-2, until I realized that 
the term was inaccurate. Using that term punishes people like me who 
take the time to read the standard or otherwise learn what the term means.


What Python does might be called USC-2+ or UCS-2e (xtended).

--
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] Re-enable warnings in regrtest and/or unittest

[Michael Foord]

On 22/11/2010 17:35, Łukasz Langa wrote:

Am 22.11.2010 18:14, schrieb Ezio Melotti:
I would like to re-enable by default warnings for regrtest and/or 
unittest.


+1

Especially in regrtest it could help manage stdlib quality (currently 
we have a horde of ResourceWarnings, zipfile mostly). I would even be 
+1 on making warnings errors for regrtest but that seems to be 
unpopular on #python-dev.




Enabling it for regrtest makes sense. For unittest I still think it is a 
choice that should be left to developers.


Michael


Best regards,
Łukasz Langa
___
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/fuzzyman%40voidspace.org.uk



--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] len(chr(i)) = 2?

[Raymond Hettinger]

On Nov 22, 2010, at 2:48 AM, Stephen J. Turnbull wrote:

> Raymond Hettinger writes:
> 
>> Neither UTF-16 nor UCS-2 is exactly correct anyway.
> 
> From a standards lawyer point of view, UCS-2 is exactly correct, 

You're twisting yourself into definitional knots.

Any explanation we give users needs to let them know two things:
* that we cover the entire range of unicode not just BMP
* that sometimes len(chr(i)) is one and sometimes two

The term UCS-2 is a complete communications failure
in that regard.  If someone looks up the term, they will
immediately see something like the wikipedia entry which says,
"UCS-2 cannot represent code points outside the BMP".
How is that helpful?


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] len(chr(i)) = 2?

[Raymond Hettinger]

On Nov 22, 2010, at 9:41 AM, Terry Reedy wrote:

> On 11/22/2010 5:48 AM, Stephen J. Turnbull wrote:
> 
>> I disagree.  I do see a problem with "UCS-2", because it fails to tell
>> us that Python implements a large number of features that make it easy
>> to do a very good job of working with non-BMP data in 16-bit builds of
> 
> Yes. As I read the standard, UCS-2 is limited to BMP chars. So I was a bit 
> confused when Python was described as UCS-2, until I realized that the term 
> was inaccurate. Using that term punishes people like me who take the time to 
> read the standard or otherwise learn what the term means.

Bingo!

Thanks for the excellent summary of the problem.

> 
> What Python does might be called USC-2+ or UCS-2e (xtended).

That would be a step in the right direction.


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

[Python-Dev] Solaris family and 64 bits compiling

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A Solaris installation contains ALWAYS 32 and 64 bits libraries. So in
any Solaris you can run 32/64 bits programs, and compile in 32 and 64 bits.

For this, libraries are stores in "/usr/lib", for instance, for 32 bits,
while the same 64 bits libraries are stored in "/usr/lib/64".

Currently, python do not considerate this.

We have Solaris 10 buildslaves, but they compile in 32 bits, aparently.
For instance
.

We now have 32 and 64 bits OpenIndiana buildslaves, so we can actually
check this. They were deployed yesterday.

Apparently the changes would be pretty simple, adding ".../64" to
library paths, to try to find the extra libraries.

What do you think?.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTOq3yZlgi5GaxT1NAQLQhAP9G2liX+YveYmfYDOuVjWWS8PE7r2wM/XA
5rik9mJM4Z7/wDnY4wrWjG5l3B9sSyrhhNI1YmIcXm4klfYxV9xTkG9dMNL+2bVc
+s98rlTdjNlMVTf8Xc7U3tMpdkG/JK0+XWmRfWsf52ATdtxPHazI9L6KvqdYjNuZ
2w3dXNXErZE=
=oYXo
-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] len(chr(i)) = 2?

[M.-A. Lemburg]

Raymond Hettinger wrote:
> Any explanation we give users needs to let them know two things:
> * that we cover the entire range of unicode not just BMP
> * that sometimes len(chr(i)) is one and sometimes two
> 
> The term UCS-2 is a complete communications failure
> in that regard.  If someone looks up the term, they will
> immediately see something like the wikipedia entry which says,
> "UCS-2 cannot represent code points outside the BMP".
> How is that helpful?

It's very helpful, since it explains why a UCS-2 build of Python
requires a surrogates pair to represent a non-BMP code point
and explains why chr(i) gives you a length 2 string rather than
a length 1 string.

A UCS-4 build does not need to use surrogates for this, hence
you get a length 1 string from chr(i).

There are two levels we have to explain to users:

1. the transfer level

2. the storage level

The UTF encodings address the transfer level and is what
you deal with in I/O. These provide variable length encodings of
the complete Unicode code point range, regardless of whether
you have a UCS-2 or a UCS-4 build.

The storage level becomes important if you want to work on
strings using indexing and slicing. Here you do have to know
whether you're dealing with a UCS-2 or a UCS-4 build, since the
indexes will vary if you're using non-BMP code points.

Finally, to tie both together, we have to explain that UTF-16
(the transfer encoding) maps to UCS-2 in a straight-forward way,
so it is possible to work with a UCS-2 build of Python and still
use the complete Unicode code point range - you only have to
take into consideration, that Python's string indexing will not
necessarily point you to n-th code point in a string, but may
well give you half or a surrogate.

Note that while that last aspect may appear like a good argument
for UCS-4 builds, in reality it is not. UCS-4 has the same
issue on a different level: the letters that get printed on
the screen or printer (graphemes) may well be made up of
multiple combining code points, e.g. an "e" and an "´".
Those again map to two indexes in the Python string, even
though, the appear to be one character on output.

Now try to explain all of the above using the terms "narrow"
and "wide" (while remembering "explicit is better than implicit"
and "avoid the temptation to guess") :-)

It is not really helpful to replace a correct and accurate
term with a fuzzy term: either way we're stuck with the
semantics.

However, the correct and accurate terms at least give
you a chance to figure out and understand the reasoning
behind the design. UCS-2 vs. UCS-4 is a trade-off, "narrow"
and "wide" is marketing talk with an implicit emphasis on
one side :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 22 2010)
>>> 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 our new mxODBC.Connect Python Database Interface 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
   http://www.egenix.com/company/contact/
___
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] Re-enable warnings in regrtest and/or unittest

[Ezio Melotti]

On 22/11/2010 19.45, Michael Foord wrote:

On 22/11/2010 17:35, Łukasz Langa wrote:

Am 22.11.2010 18:14, schrieb Ezio Melotti:
I would like to re-enable by default warnings for regrtest and/or 
unittest.


+1

Especially in regrtest it could help manage stdlib quality (currently 
we have a horde of ResourceWarnings, zipfile mostly). I would even be 
+1 on making warnings errors for regrtest but that seems to be 
unpopular on #python-dev.




As I said on IRC I think it makes sense to turn them into errors once we 
fixed/silenced all the ones that we have now. That would help keeping 
the number of warning to 0.




Enabling it for regrtest makes sense. For unittest I still think it is 
a choice that should be left to developers.


If we consider that most of the developers want to see them, I'd prefer 
to have the warnings by default rather than having to use -Wd explicitly 
every time I run the tests (keep in mind that many developers out there 
don't even know/remember that now they should use -Wd).





Michael


Best regards,
Łukasz Langa
___
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/fuzzyman%40voidspace.org.uk





___
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] len(chr(i)) = 2?

[Alexander Belopolsky]

On Mon, Nov 22, 2010 at 12:41 PM, Terry Reedy  wrote:
..
> What Python does might be called USC-2+ or UCS-2e (xtended).
>

Wow!  I am not the only one who can't get the order of letters right
in these acronyms.  (I am usually consistent within one sentence,
though.) :-)

I-can't-spell-three-letter-acronyms-right-ly yours ...
___
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] Solaris family and 64 bits compiling

[Brett Cannon]

On Mon, Nov 22, 2010 at 10:34, Jesus Cea  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> A Solaris installation contains ALWAYS 32 and 64 bits libraries. So in
> any Solaris you can run 32/64 bits programs, and compile in 32 and 64 bits.
>
> For this, libraries are stores in "/usr/lib", for instance, for 32 bits,
> while the same 64 bits libraries are stored in "/usr/lib/64".
>
> Currently, python do not considerate this.
>
> We have Solaris 10 buildslaves, but they compile in 32 bits, aparently.
> For instance
> .
>
> We now have 32 and 64 bits OpenIndiana buildslaves, so we can actually
> check this. They were deployed yesterday.
>
> Apparently the changes would be pretty simple, adding ".../64" to
> library paths, to try to find the extra libraries.
>
> What do you think?.

Are you asking about buildbots only or as a general policy? If you are
asking about the buildbots then I definitely think we should use 64
bits. If you are asking about policy I would say it should be an
option in case people are using C extensions that are not designed to
work with 64 bits.
___
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] Re-enable warnings in regrtest and/or unittest

[Brett Cannon]

On Mon, Nov 22, 2010 at 10:58, Ezio Melotti  wrote:
> On 22/11/2010 19.45, Michael Foord wrote:
>>
>> On 22/11/2010 17:35, Łukasz Langa wrote:
>>>
>>> Am 22.11.2010 18:14, schrieb Ezio Melotti:

 I would like to re-enable by default warnings for regrtest and/or
 unittest.
>>>
>>> +1
>>>
>>> Especially in regrtest it could help manage stdlib quality (currently we
>>> have a horde of ResourceWarnings, zipfile mostly). I would even be +1 on
>>> making warnings errors for regrtest but that seems to be unpopular on
>>> #python-dev.
>>>
>
> As I said on IRC I think it makes sense to turn them into errors once we
> fixed/silenced all the ones that we have now. That would help keeping the
> number of warning to 0.

I agree.

>
>>
>> Enabling it for regrtest makes sense. For unittest I still think it is a
>> choice that should be left to developers.
>
> If we consider that most of the developers want to see them, I'd prefer to
> have the warnings by default rather than having to use -Wd explicitly every
> time I run the tests (keep in mind that many developers out there don't even
> know/remember that now they should use -Wd).

The problem with that is it means developers who switch to Python 3.2
or whatever are suddenly going to have their tests fail until they
update their code to turn the warnings off. Then again, if we make the
switch for this dead simple to add and backwards-compatible so that
turning them off doesn't trigger an error in older versions then I am
all for turning warnings on by default.

Another approach is to have unittest's runner, when run in verbose
mode, print out what the warnings filter is set to so developers are
aware that they are silencing warnings.

-Brett

>
>
>>
>> Michael
>>
>>> Best regards,
>>> Łukasz Langa
>>> ___
>>> 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/fuzzyman%40voidspace.org.uk
>>
>>
>
> ___
> 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/brett%40python.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] Solaris family and 64 bits compiling

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/11/10 20:12, Brett Cannon wrote:
> Are you asking about buildbots only or as a general policy? If you are
> asking about the buildbots then I definitely think we should use 64
> bits. If you are asking about policy I would say it should be an
> option in case people are using C extensions that are not designed to
> work with 64 bits.

The point is that building python in 64 bits under Solaris (family) is
not easy, because the 64 bits libraries (zlib, openssl, berkeley db,
curses, etc., etc., etc) are not is "/usr/lib", "/usr/local/lib", etc.,
but "/usr/lib/64", "/usr/local/lib/64", etc.

Solaris overcomes most of the issue having separate library searchpath
in 32 and 64 bits (via the "crle" command). But in some cases python try
to find some library in "/usr/local/lib", and my point is that it should
search TOO inside "/usr/local/lib/64".

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTOrD8Jlgi5GaxT1NAQJhRQP/dd4q70eXsq5AUFrleqUx3A+AagChpCcp
UDHAomaX26cMl0tLFwLOd4SaKizzRMvjdTJc3GhZDIqYrF3QuqZAyLPjr5tyogP8
/4KPM73l5L2cb7IdHdSHpruwMh8f2WJ4S6+ig8DzOj6qBcttXKMymrV/skum4ENJ
yb4mbpH9q/0=
=Oe2G
-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] issue 9807 - abiflags in paths and symlinks (updated patch)

[Barry Warsaw]

On Nov 10, 2010, at 04:27 PM, Barry Warsaw wrote:

>I finally found a chance to address all the outstanding technical issues
>mentioned in bug 9807:
>
>http://bugs.python.org/issue9807
>
>I've uploaded a new patch which contains the rest of the changes I'm
>proposing.  I think we still need consensus about whether these changes are
>good to commit.  With 3.2b1 coming soon, now's the time to do that.
>
>If there are any remaining concerns about the details of the patch, please add
>them to the tracker issue.  If you have any remaining objections to the
>change, please let me know or follow up here.

The patch has now been updated to address the last few comments in the tracker
issue.  I am now ready to commit it to py3k.  If there are any remaining
objections or concerns, please reply here or update the tracker issue.
Otherwise, I plan to commit this to py3k on Wednesday.

Cheers,
-Barry


signature.asc
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] Solaris family and 64 bits compiling

[Martin v. Löwis]

> Solaris overcomes most of the issue having separate library searchpath
> in 32 and 64 bits (via the "crle" command). But in some cases python try
> to find some library in "/usr/local/lib", and my point is that it should
> search TOO inside "/usr/local/lib/64".

I don't think this will work. If the linker finds a library of the wrong
ELF type, then it will choke.

Before enabling anything on a build slave, a patch needs to be
contributed to make it work in the first place.

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] len(chr(i)) = 2?

[R. David Murray]

On Mon, 22 Nov 2010 12:37:59 -0500, Alexander Belopolsky 
 wrote:
> On Mon, Nov 22, 2010 at 12:30 PM, R. David Murray  
> wrote:
> ..
> > For reference, a grep in py3k/Doc reveals that there are currently exactly
> > 23 lines mentioning UCS2 or UCS4 in the docs.
> 
> Did you grep for USC-2 and USC-4 as well?  I have to admit that my
> aversion to these terms is mostly due to the fact that I don't know
> how to spell them correctly. :-)

I grepped using "-ri ucs." and eliminated the false positives (of
which there were only a few) by hand.

--
R. David Murray  www.bitdance.com
___
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] Re-enable warnings in regrtest and/or unittest

[Guido van Rossum]

On Mon, Nov 22, 2010 at 11:24 AM, Brett Cannon  wrote:
> The problem with that is it means developers who switch to Python 3.2
> or whatever are suddenly going to have their tests fail until they
> update their code to turn the warnings off.

That sounds like a feature to me... :-)

-- 
--Guido van Rossum (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] Solaris family and 64 bits compiling

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/11/10 20:42, "Martin v. Löwis" wrote:
> Before enabling anything on a build slave, a patch needs to be
> contributed to make it work in the first place.

I actually agree. I am not sure yet, but I am thinking that adding a
"--build-64" parameter to "configure" could be an option under Solaris.
Most OSs (let say, Linux) force you to choose 32/64 bits at install
time, but Solaris can use both at the same time, and compilers allow to
compile both (using -m32 or -m64).

Since choosing 32 or 64 bits when compiling python under Solaris change
the requirement, paths, etc., automating it should be a goal.

PS: Martin, is there any reason to restrict the solaris 10 buildslaves
to 32 bits, beside the said problems?.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTOrhKZlgi5GaxT1NAQI0cAP+OUFGVDd7UV6MdHzMenBn8fO3h4M1n0dR
UZrVyYJhUYvEX9p7MRBdDNFY/6LrUITb3WCVegD3PuOymQP16GgksRfIA/jGDXyl
Fe+Ed5amlDgdVPeVVH/55OodrO4SuOrJZ846G6GB1wav2IjR7I9YGxZQ6PA0LR7l
4Iph6HfcMlw=
=hTNy
-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] is this a bug? no environment variables

[Glenn Linderman]

On 11/22/2010 8:33 AM, Guido van Rossum wrote:

On Sun, Nov 21, 2010 at 9:40 PM, Glenn Linderman  wrote:

In reviewing my notes from my experimentations with CGIHTTPServer
(Python2.6) and then http.server (Python 3.2a4), I note one behavior I
haven't reported as a bug, nor do I know where to start to figure it out,
other than experimentally.

The experiment: launching CGIHTTPServer without environment variables, by
the simple expedient of using a batch file to unset all the existing
environment variables, and then launching Python2.6 with CGIHTTPServer.

So it failed early: random.py fails at line 110 (Python 2.6).

What specific traceback do you get? In my copy of the code that line says

 a = long(_hexlify(_urandom(16)), 16)

and I could just imagine that _urandom() fails for some reason to do
with the environment (it is a reference to os.urandom()), which, being
part of the C library code, might depend on the environment.

But you're not giving enough info to debug this.


Yep, that's the line.  I'll have to re-run the scenario, but will do it 
on 3.2a4, hopefully tonight or tomorrow, to get the traceback.




I suppose it is possible that some environment variables are used by Python
directly (but I can't seem to find a documented list of them) although I
would expect that usage to be optional, with fall-back defaults when they
don't exist.

That is certainly the idea, but the fallbacks may not always be nice.

Environment variables used by Python or the stdlib itself are supposed
to be named PYTHON  if they are Python-specific, and there's
a way to disable all of these (-E). But there are other environment
variables (HOME and PATH come to mind) that have a broader definition
and that are used in some part of the stdlib. Plus, as I mentioned,
who knows what the non-Python C library uses (well, somebody probably
knows, but I don't know of a central source that we can actually trust
across the many platforms where Python runs).


OK, thanks for the philosophy statement.  That's what I didn't know, 
being new.



I suppose it is even possible that some Windows APIs might
depend on some environment variables, but I expected that the registry had
replaced such usage completely, by now, with the environment variables
mostly being a convenience tool for batch files, or for optional, temporary
alteration of particular settings.

That sounds like wishful thinking. :-)


Well, wishful thinking from me regarding the Windows and the registry is 
that Windows would be better off without a registry.  But it seemed like 
their direction was instead to do away with environment variables, but 
in any case, I have little idea if they've achieved it, but should have 
achieved something in 6.1 versions of Windows!
___
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] Re-enable warnings in regrtest and/or unittest

[Michael Foord]

On 22/11/2010 21:08, Guido van Rossum wrote:

On Mon, Nov 22, 2010 at 11:24 AM, Brett Cannon  wrote:

The problem with that is it means developers who switch to Python 3.2
or whatever are suddenly going to have their tests fail until they
update their code to turn the warnings off.

That sounds like a feature to me... :-)

I think Ezio was suggesting just turning warnings on by default when 
unittest is run, not turning them into errors. Ezio is suggesting that 
developers could explicitly turn warnings off again, but when you use 
the default test runner warnings would be shown. His logic is that 
warnings are for developers, and so are tests...


Michael

--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] Solaris family and 64 bits compiling

[Martin v. Löwis]

> I actually agree. I am not sure yet, but I am thinking that adding a
> "--build-64" parameter to "configure" could be an option under Solaris.
> Most OSs (let say, Linux) force you to choose 32/64 bits at install
> time

Actually, that's not at all the case. Most systems these days support
32-bit and 64-bit applications simultaneously, and also support compiler
tool chains that allow building for either mode.
Solaris, Linux, and Windows are about on-par in this respect;
OS X is more advanced as it allows to have a single binary that
supports both 32-bit and 64-bit execution (making the need for adjusted
path names irrelevant).

> Since choosing 32 or 64 bits when compiling python under Solaris change
> the requirement, paths, etc., automating it should be a goal.
> 
> PS: Martin, is there any reason to restrict the solaris 10 buildslaves
> to 32 bits, beside the said problems?.

I don't see that as a restriction. I have to make a choice, and there
are sooo many choices to make:
- gcc vs. SunPRO
- 32-bit vs. 64-bit
- GNU make vs. /usr/ccs/bin/make

I picked the combination which was most easy to setup, and is therefore
likely to be used by most users (except for those who think 64-bit
is somehow "better" than 32-bit, when it is actually the other way
'round - IMO).

As for configuration, I personally prefer that setting CC indicates
what type of build you want. Set CC to "gcc -m64" to indicate a
64-build. Ideally, you will *not* have to adjust library paths, since
the other compiler will know on its own where to search things.

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] Solaris family and 64 bits compiling

[Ned Deily]

In article <4ceae129.2060...@jcea.es>, Jesus Cea  wrote:
> On 22/11/10 20:42, "Martin v. Löwis" wrote:
> > Before enabling anything on a build slave, a patch needs to be
> > contributed to make it work in the first place.
> 
> I actually agree. I am not sure yet, but I am thinking that adding a
> "--build-64" parameter to "configure" could be an option under Solaris.
> Most OSs (let say, Linux) force you to choose 32/64 bits at install
> time, but Solaris can use both at the same time, and compilers allow to
> compile both (using -m32 or -m64).
> 
> Since choosing 32 or 64 bits when compiling python under Solaris change
> the requirement, paths, etc., automating it should be a goal.

You might want to look at the existing --with-universal-archs=ARCH in 
configure for how this is done for OS X builds.  It's probably both 
simpler and more complicated than would be needed elsewhere: on OS X, a 
single file can contain object codes for multiple architectures, e.g 
32-bit and 64-bit, rather than having to have multiple files.

-- 
 Ned Deily,
 n...@acm.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] Re-enable warnings in regrtest and/or unittest

[Brett Cannon]

On Mon, Nov 22, 2010 at 13:08, Guido van Rossum  wrote:
> On Mon, Nov 22, 2010 at 11:24 AM, Brett Cannon  wrote:
>> The problem with that is it means developers who switch to Python 3.2
>> or whatever are suddenly going to have their tests fail until they
>> update their code to turn the warnings off.
>
> That sounds like a feature to me... :-)

=) I meant update their tests with the switch to turn off the
warnings, not update to make the warnings properly disappear.

I guess it's a question of whether it will be errors by default or
simply output the warning. I can get behind printing the warnings by
default and adding a switch to make them errors or off otherwise.

-Brett

>
> --
> --Guido van Rossum (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

[Python-Dev] Missing Python Symbols when Starting Python App (Apache/Django/Mod_Wsgi)

[Anurag Chourasia]

All,

I have a problem in starting my Python(Django) App using Apache and Mod_Wsgi

I am using Django 1.2.3 and Python 2.6.6 running on Apache 2.2.17 with
Mod_Wsgi 3.3

When I try to access the app from Web Browser, I am getting these
errors.

[Mon Nov 22 09:45:25 2010] [notice] Apache/2.2.17 (Unix) mod_wsgi/3.3
Python/2.6.6 configured -- resuming normal operations

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] mod_wsgi
(pid=1273874): Target WSGI script '/u01/home/apli/wm/app/gdd/pyserver/
apache/django.wsgi' cannot be loaded as Python module.

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] mod_wsgi
(pid=1273874): Exception occurred processing WSGI script '/u01/home/
apli/wm/app/gdd/pyserver/apache/django.wsgi'.

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] Traceback
(most recent call last):

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   File "/u01/
home/apli/wm/app/gdd/pyserver/apache/django.wsgi", line 19, in


[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] import
django.core.handlers.wsgi

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   File "/usr/
local/lib/python2.6/site-packages/django/core/handlers/wsgi.py", line
1, in 

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] from
threading import Lock

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   File "/usr/
local/lib/python2.6/threading.py", line 13, in 

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] from
functools import wraps

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   File "/usr/
local/lib/python2.6/functools.py", line 10, in 

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] from
_functools import partial, reduce

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] ImportError:
rtld: 0712-001 Symbol PyArg_UnpackTuple was referenced

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   from
module /usr/local/lib/python2.6/lib-dynload/_functools.so(), but a
runtime definition


[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   of the
symbol was not found.

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] rtld:
0712-001 Symbol PyCallable_Check was referenced

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   from
module /usr/local/lib/python2.6/lib-dynload/_functools.so(), but a
runtime definition

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   of the
symbol was not found.

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] rtld:
0712-001 Symbol PyDict_Copy was referenced


[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   from
module /usr/local/lib/python2.6/lib-dynload/_functools.so(), but a
runtime definition

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   of the
symbol was not found.

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] rtld:
0712-001 Symbol PyDict_Merge was referenced

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   from
module /usr/local/lib/python2.6/lib-dynload/_functools.so(), but a
runtime definition

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   of the
symbol was not found.

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] rtld:
0712-001 Symbol PyDict_New was referenced

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   from
module /usr/local/lib/python2.6/lib-dynload/_functools.so(), but a
runtime definition

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   of the
symbol was not found.

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] rtld:
0712-001 Symbol PyErr_Occurred was referenced

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   from
module /usr/local/lib/python2.6/lib-dynload/_functools.so(), but a
runtime definition

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   of the
symbol was not found.

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] rtld:
0712-001 Symbol PyErr_SetString was referenced

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   from
module /usr/local/lib/python2.6/lib-dynload/_functools.so(), but a
runtime definition

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191]   of the
symbol was not found.

[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] \t0509-021
Additional errors occurred but are not reported.


I assume that those missing runtime definitions are supposed to be in
the Python executable. Doing an nm on the first missing symbol reveals
that it does exist.

root [zibal]% nm  /usr/local/bin/python | grep -i PyArg_UnpackTuple
.PyArg_UnpackTuple   T   268683204 524
PyArg_UnpackTupleD   537073500
PyArg_UnpackTupled   537073500  12
PyArg_UnpackTuple:F-1 - 224

Please guide.

Regards,
Guddu
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/p

Re: [Python-Dev] Solaris family and 64 bits compiling

[Éric Araujo]

Hi,

I think this bug is related: http://bugs.python.org/issue1294959
“Problems with /usr/lib64 builds.”

Regards

___
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] is this a bug? no environment variables

[Tim Lesher]

On Mon, Nov 22, 2010 at 16:54, Glenn Linderman  wrote:
> I suppose it is possible that some environment variables are used by Python
> directly (but I can't seem to find a documented list of them) although I
> would expect that usage to be optional, with fall-back defaults when they
> don't exist.

I can verify that that's the case: Python (at least through 3.1.2)
runs fine on Windows platforms when environment variables are
completely unavailable.  I know that from running our port for Windows
CE (which has no environment variables at all), cross-compiled for
Windows XP.
-- 
Tim Lesher 
___
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] Solaris family and 64 bits compiling

[Martin v. Löwis]

Am 22.11.2010 23:51, schrieb Éric Araujo:
> Hi,
> 
> I think this bug is related: http://bugs.python.org/issue1294959
> “Problems with /usr/lib64 builds.”

Perhaps more closely related:

http://bugs.python.org/issue847812
http://bugs.python.org/issue1733484
http://bugs.python.org/issue1676121
http://bugs.python.org/issue1628484

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] Solaris family and 64 bits compiling

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/11/10 23:05, "Martin v. Löwis" wrote:
>> PS: Martin, is there any reason to restrict the solaris 10 buildslaves
>> to 32 bits, beside the said problems?.
> 
> I don't see that as a restriction. I have to make a choice, and there
> are sooo many choices to make:
> - gcc vs. SunPRO
> - 32-bit vs. 64-bit
> - GNU make vs. /usr/ccs/bin/make
> 
> I picked the combination which was most easy to setup, and is therefore
> likely to be used by most users (except for those who think 64-bit
> is somehow "better" than 32-bit, when it is actually the other way
> 'round - IMO).

Do not think this is a personal attack. Not at all. I am deploying 32
and 64 bits buildslaves (in the same machine) and feeling the pain. You
are far more experiences than me with buildbots and python. I want to
know if I am missing something.

> As for configuration, I personally prefer that setting CC indicates
> what type of build you want. Set CC to "gcc -m64" to indicate a
> 64-build. Ideally, you will *not* have to adjust library paths, since
> the other compiler will know on its own where to search things.

The problem is not with system library paths. Compilers overcome that.
The problem is with things like "/usr/local/lib" and hardcoded library
paths in Python.

For example, checking
:

"""
gcc -shared -m64
build/temp.solaris-2.11-i86pc-3.2-pydebug/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/readline.o
- -L/usr/lib/termcap -L/usr/local/lib -lreadline -lncursesw -o
build/lib.solaris-2.11-i86pc-3.2-pydebug/readline.so
ld: fatal: file /usr/local/lib/libncursesw.so: wrong ELF class: ELFCLASS32
ld: fatal: file processing errors. No output written to
build/lib.solaris-2.11-i86pc-3.2-pydebug/readline.so
collect2: ld returned 1 exit status
"""

The "-L/usr/local/lib" should be "-L/usr/local/lib/64". An example of many.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTOr/n5lgi5GaxT1NAQLzogP/Sb2VMe7UwK/YeB8/cQSxhuoKeNRre0pZ
XCJDePusysqI3uXBHmH8vitEIILmUKd5kQ6vsFwErPIry7ikl2fbDHe7eQgNr2HK
o5Xcul36bqtuKWGkDV+gIyBH/m9k4pkvc7Lfp3mvR7yiYTBB75V/azt64XSTC9si
7QjjetX5wnA=
=NCtE
-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] [Python-checkins] r86699 - python/branches/py3k/Lib/zipfile.py

[Benjamin Peterson]

No test?

2010/11/22 lukasz.langa :
> Author: lukasz.langa
> Date: Tue Nov 23 00:31:26 2010
> New Revision: 86699
>
> Log:
> Issue #9846: ZipExtFile provides no mechanism for closing the underlying file 
> object
>
>
>
> Modified:
>   python/branches/py3k/Lib/zipfile.py
>
> Modified: python/branches/py3k/Lib/zipfile.py
> ==
> --- python/branches/py3k/Lib/zipfile.py (original)
> +++ python/branches/py3k/Lib/zipfile.py Tue Nov 23 00:31:26 2010
> @@ -473,9 +473,11 @@
>     # Search for universal newlines or line chunks.
>     PATTERN = re.compile(br'^(?P[^\r\n]+)|(?P\n|\r\n?)')
>
> -    def __init__(self, fileobj, mode, zipinfo, decrypter=None):
> +    def __init__(self, fileobj, mode, zipinfo, decrypter=None,
> +                 close_fileobj=False):
>         self._fileobj = fileobj
>         self._decrypter = decrypter
> +        self._close_fileobj = close_fileobj
>
>         self._compress_type = zipinfo.compress_type
>         self._compress_size = zipinfo.compress_size
> @@ -647,6 +649,12 @@
>         self._offset += len(data)
>         return data
>
> +    def close(self):
> +        try:
> +            if self._close_fileobj:
> +                self._fileobj.close()
> +        finally:
> +            super().close()
>
>
>  class ZipFile:
> @@ -889,8 +897,10 @@
>         # given a file object in the constructor
>         if self._filePassed:
>             zef_file = self.fp
> +            should_close = False
>         else:
>             zef_file = io.open(self.filename, 'rb')
> +            should_close = True
>
>         # Make sure we have an info object
>         if isinstance(name, ZipInfo):
> @@ -944,7 +954,7 @@
>             if h[11] != check_byte:
>                 raise RuntimeError("Bad password for file", name)
>
> -        return  ZipExtFile(zef_file, mode, zinfo, zd)
> +        return  ZipExtFile(zef_file, mode, zinfo, zd, 
> close_fileobj=should_close)
>
>     def extract(self, member, path=None, pwd=None):
>         """Extract a member from the archive to the current working directory,
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>



-- 
Regards,
Benjamin
___
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] Solaris family and 64 bits compiling

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think this is probably trivial, but is there any foolproof way to
detect 64 bit builds in python, beside "sys.maxint"?.

And any macro useable for conditional compilation in C?.

Checking Solaris 10 header files, I see macros like "_LP64". Portability
would be nice, but in this personal case, probably unneeded...

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTOsBNplgi5GaxT1NAQLkJwP+P1YyABBPGInHJXvwsU2ZLuj+u/OuZCRE
m6hmbZgMajAyc5NtTie36qyHKAtVBcxFFvUdDeyfDZXV5gU+dF9Ha7/R16dclG3k
b5W0CbccnGFcQJ/XypNPjH2dYPFDiqF8kCkDfeLJ7ZyL9ojA1YlRGFrgswN77/cF
XM7Cwq1mh5k=
=JXDq
-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] Missing Python Symbols when Starting Python App (Apache/Django/Mod_Wsgi)

[Terry Reedy]

On 11/22/2010 5:46 PM, Anurag Chourasia wrote:


[Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] mod_wsgi
(pid=1273874): Target WSGI script '/u01/home/apli/wm/app/gdd/pyserver/
apache/django.wsgi' cannot be loaded as Python module.


All other error stem probably from this.


Please guide.


Ask usage questions like this on python-list or a django-specific list.
python-list is for discussion of development of future versions of 
Python, not usage of current versions.


--
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] Solaris family and 64 bits compiling

[Martin v. Löwis]

Am 23.11.2010 00:41, schrieb Jesus Cea:
> On 22/11/10 23:05, "Martin v. Löwis" wrote:
>>> PS: Martin, is there any reason to restrict the solaris 10 buildslaves
>>> to 32 bits, beside the said problems?.
> 
>> I don't see that as a restriction. I have to make a choice, and there
>> are sooo many choices to make:
>> - gcc vs. SunPRO
>> - 32-bit vs. 64-bit
>> - GNU make vs. /usr/ccs/bin/make
> 
>> I picked the combination which was most easy to setup, and is therefore
>> likely to be used by most users (except for those who think 64-bit
>> is somehow "better" than 32-bit, when it is actually the other way
>> 'round - IMO).
> 
> Do not think this is a personal attack.

No offense taken. If you really want to know the historical background:
this was the very first build slave (before I actually announced it to
python-dev), and I haven't changed much from the initial setup.

I just point out that none of the binaries in /usr/bin is a 64-bit
binary; this includes the Sun-provided /usr/sfw/bin/python

> The "-L/usr/local/lib" should be "-L/usr/local/lib/64". An example of many.

Is that really the case? I.e. will ncurses automatically install into
/usr/local/lib/64 if built with a 64-bit compiler? My installation
doesn't even have a /usr/local/lib/64 folder.

In any case: this shouldn't need a configure option. Instead, Python can
find out itself whether it's a 64-bit build, and make modifications
it considers necessary.

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] Solaris family and 64 bits compiling

[Antoine Pitrou]

On Tue, 23 Nov 2010 00:48:06 +0100
Jesus Cea  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I think this is probably trivial, but is there any foolproof way to
> detect 64 bit builds in python, beside "sys.maxint"?.

sys.maxsize

> And any macro useable for conditional compilation in C?.

SIZEOF_VOID_P > 4



___
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] Solaris family and 64 bits compiling

[Brian Curtin]

On Mon, Nov 22, 2010 at 17:48, Jesus Cea  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I think this is probably trivial, but is there any foolproof way to
> detect 64 bit builds in python, beside "sys.maxint"?.
>

import platform
platform.architecture()
___
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] Solaris family and 64 bits compiling

[Martin v. Löwis]

Am 23.11.2010 00:48, schrieb Jesus Cea:
> I think this is probably trivial, but is there any foolproof way to
> detect 64 bit builds in python, beside "sys.maxint"?.

The canonical way is to use platform.architecture().

> And any macro useable for conditional compilation in C?.

You need to be more specific than that. There are perhaps ten
independent properties you may query, depending on what precise problem
you try to solve. Most likely, you are looking for SIZEOF_VOID_P
(but don't use that unless you literally want to know how many bytes
a pointer uses, or whether it uses 4 or 8 bytes).

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] [Python-checkins] r86699 - python/branches/py3k/Lib/zipfile.py

[Łukasz Langa]

Wiadomość napisana przez Benjamin Peterson w dniu 2010-11-23, o godz. 00:47:

> No test?
> 

The tests were there already, raising ResourceWarnings. After this change, they 
stopped doing that. You may say: now they pass for the first time :)

Best regards,
Łukasz


> 2010/11/22 lukasz.langa :
>> Author: lukasz.langa
>> Date: Tue Nov 23 00:31:26 2010
>> New Revision: 86699
>> 
>> Log:
>> Issue #9846: ZipExtFile provides no mechanism for closing the underlying 
>> file object
>> 
>> 
>> 
>> Modified:
>>   python/branches/py3k/Lib/zipfile.py
>> 
>> Modified: python/branches/py3k/Lib/zipfile.py
>> ==
>> --- python/branches/py3k/Lib/zipfile.py (original)
>> +++ python/branches/py3k/Lib/zipfile.py Tue Nov 23 00:31:26 2010
>> @@ -473,9 +473,11 @@
>> # Search for universal newlines or line chunks.
>> PATTERN = re.compile(br'^(?P[^\r\n]+)|(?P\n|\r\n?)')
>> 
>> -def __init__(self, fileobj, mode, zipinfo, decrypter=None):
>> +def __init__(self, fileobj, mode, zipinfo, decrypter=None,
>> + close_fileobj=False):
>> self._fileobj = fileobj
>> self._decrypter = decrypter
>> +self._close_fileobj = close_fileobj
>> 
>> self._compress_type = zipinfo.compress_type
>> self._compress_size = zipinfo.compress_size
>> @@ -647,6 +649,12 @@
>> self._offset += len(data)
>> return data
>> 
>> +def close(self):
>> +try:
>> +if self._close_fileobj:
>> +self._fileobj.close()
>> +finally:
>> +super().close()
>> 
>> 
>>  class ZipFile:
>> @@ -889,8 +897,10 @@
>> # given a file object in the constructor
>> if self._filePassed:
>> zef_file = self.fp
>> +should_close = False
>> else:
>> zef_file = io.open(self.filename, 'rb')
>> +should_close = True
>> 
>> # Make sure we have an info object
>> if isinstance(name, ZipInfo):
>> @@ -944,7 +954,7 @@
>> if h[11] != check_byte:
>> raise RuntimeError("Bad password for file", name)
>> 
>> -return  ZipExtFile(zef_file, mode, zinfo, zd)
>> +return  ZipExtFile(zef_file, mode, zinfo, zd, 
>> close_fileobj=should_close)
>> 
>> def extract(self, member, path=None, pwd=None):
>> """Extract a member from the archive to the current working 
>> directory,
>> ___
>> Python-checkins mailing list
>> python-check...@python.org
>> http://mail.python.org/mailman/listinfo/python-checkins
>> 
> 
> 
> 
> -- 
> Regards,
> Benjamin
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins

-- 
Pozdrawiam serdecznie,
Łukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/

___
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] Missing Python Symbols when Starting Python App (Apache/Django/Mod_Wsgi)

[Reinout van Rees]

On 11/22/2010 11:46 PM, Anurag Chourasia wrote:


I have a problem in starting my Python(Django) App using Apache and Mod_Wsgi


I'm pretty sure you're asking on the wrong list.  This one is for 
discussing development of python-the-language :-)


You'd better head over to the django-user mailinglist, for instance via 
http://groups.google.com/group/django-users




Reinout


--
Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org
Collega's gezocht!
Django/python vacature in Utrecht: http://tinyurl.com/35v34f9

___
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] Re-enable warnings in regrtest and/or unittest

[Łukasz Langa]

Wiadomość napisana przez Michael Foord w dniu 2010-11-22, o godz. 23:01:

> On 22/11/2010 21:08, Guido van Rossum wrote:
>> On Mon, Nov 22, 2010 at 11:24 AM, Brett Cannon  wrote:
>>> The problem with that is it means developers who switch to Python 3.2
>>> or whatever are suddenly going to have their tests fail until they
>>> update their code to turn the warnings off.
>> That sounds like a feature to me... :-)
>> 
> I think Ezio was suggesting just turning warnings on by default when unittest 
> is run, not turning them into errors. Ezio is suggesting that developers 
> could explicitly turn warnings off again, but when you use the default test 
> runner warnings would be shown. His logic is that warnings are for 
> developers, and so are tests...

Then again, he is not against the idea to turn those warnings into errors, at 
least for regrtest.

If you agree to do that for regrtest I will clean up the tests for warnings. 
Already did that for zipfile so it doesn't raise ResourceWarnings anymore. I 
just need to correct multiprocessing and xmlrpc ResourceWarnings, silence some 
DeprecationWarnings in the tests and we're all set. Ah, I see a couple more 
with -uall but nothing scary.

Anyway, I find warnings as errors in regrtest a welcome feature. Let's make it 
happen :)

-- 
Best regards,
Łukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/

___
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] Solaris family and 64 bits compiling

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 23/11/10 01:05, "Martin v. Löwis" wrote:
> No offense taken. If you really want to know the historical background:
> this was the very first build slave (before I actually announced it to
> python-dev), and I haven't changed much from the initial setup.

I do really want to know. I love trivia :-). Thanks.

> I just point out that none of the binaries in /usr/bin is a 64-bit
> binary; this includes the Sun-provided /usr/sfw/bin/python
> 
>> The "-L/usr/local/lib" should be "-L/usr/local/lib/64". An example of many.
> 
> Is that really the case? I.e. will ncurses automatically install into
> /usr/local/lib/64 if built with a 64-bit compiler? My installation
> doesn't even have a /usr/local/lib/64 folder.

A fresh Solaris 10 install doesn't even have a "/usr/local" directory :).

Sadly today most Open Source code is written like if Linux were the only
Unix system out there.

I was amazed that OpenSSL 1.0 installs automatically in
"/usr/local/ssl/lib" when compiled in 32 bits, and in
"/usr/local/ssl/lib/64" when compiled in 64 bits. I almost cry.

> In any case: this shouldn't need a configure option. Instead, Python can
> find out itself whether it's a 64-bit build, and make modifications
> it considers necessary.

I agree. Python should detect it automatically and update the paths when
compiling.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTOsPBZlgi5GaxT1NAQIw+QP/ZuxpWo2WZYUUcDfARRnOtp60n4PbIGMf
fqQ4ZnC9JnelzKDU9kBo0yReL2zYAw0ZwezsGwZ98M9i3XyKkFCtcJcM1vXpIsDL
eBwga8kPDpab5loP/vuac5kVC0wn0Z0z8x+BRMW6mwoOMHJzd463E8GTQywdx3x1
06FUHwJ0Hv4=
=PV43
-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] Solaris family and 64 bits compiling

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 23/11/10 01:05, "Martin v. Löwis" wrote:
> I just point out that none of the binaries in /usr/bin is a 64-bit
> binary; this includes the Sun-provided /usr/sfw/bin/python

True. This is for simplicity reasons (provide only one binary valid for
32 and 64 bits CPUs) and because 64 bits is overkill for a lot of stuff.

In my own system my only 64 bits libraries are OpenSSL, GMP, and some
multimedia stuff like mencoder, vorbis, etc, where the difference is big.

And the GCC 4.5.x install, that installs libraries (fortran, stdc++,
objective C, etc) automatically under "/usr/local/lib/64". GOOD.

But if we say the Python can be compiled as 64 bits under Solaris, would
be nice if that was actually true. Now that we have a buildbot (under
OpenIndiana) to test, it is doable.

If not, we could say that Solaris+64 bits is unsupported. I don't think
we should go that way. Solaris+64 bits should be a full citizen.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTOsRxplgi5GaxT1NAQKqqAP/fkiPpnPswMYOWc30Bflg3nDqRf6ih1bW
ZZYHEMuJN9C8rm419LnRtoTyeAruHQYJ3o/dAoA2xDZu1xDYz8OOJKzG1L8hRVce
OGm9TmziS4zuwWS4sYdmh21/ZCuD0MVq3gqD1h8zYPwrqbTTA6shYr6/He5hAo6j
5PsYWj4gIAE=
=Rr80
-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] [Python-checkins] r86699 - python/branches/py3k/Lib/zipfile.py

[Benjamin Peterson]

2010/11/22 Łukasz Langa :
> Wiadomość napisana przez Benjamin Peterson w dniu 2010-11-23, o godz. 00:47:
>
> No test?
>
>
> The tests were there already, raising ResourceWarnings. After this change,
> they stopped doing that. You may say: now they pass for the first time :)

It looks like you added new API, though. For that, we would expect new tests.



-- 
Regards,
Benjamin
___
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

[Python-Dev] OpenSSL Voluntarily (openssl-1.0.0a)

[Hirokazu Yamamoto]

Hello. Does this affect python? Thank you.

http://www.openssl.org/news/secadv_20101116.txt
___
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] OpenSSL Voluntarily (openssl-1.0.0a)

[Glyph Lefkowitz]

On Mon, Nov 22, 2010 at 11:13 PM, Hirokazu Yamamoto <
ocean-c...@m2.ccsnet.ne.jp> wrote:

> Hello. Does this affect python? Thank you.
>
> http://www.openssl.org/news/secadv_20101116.txt
>

No.
___
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] [Python-checkins] r86702 - python/branches/py3k/Lib/idlelib/IOBinding.py

[Terry Reedy]

On 11/23/2010 1:01 AM, terry.reedy wrote:

Author: terry.reedy
Date: Tue Nov 23 07:01:31 2010
New Revision: 86702

Log:

Issue 9222 Fix filetypes for open dialog

Sorry, forgot to add this before clicking [go] or whatever the button 
is. Is there any way to revise a revision ;-?



Modified:
python/branches/py3k/Lib/idlelib/IOBinding.py

Modified: python/branches/py3k/Lib/idlelib/IOBinding.py
==
--- python/branches/py3k/Lib/idlelib/IOBinding.py   (original)
+++ python/branches/py3k/Lib/idlelib/IOBinding.py   Tue Nov 23 07:01:31 2010
@@ -476,8 +476,8 @@
  savedialog = None

  filetypes = [
-("Python and text files", "*.py *.pyw *.txt", "TEXT"),
-("All text files", "*", "TEXT"),
+("Python files", "*.py *.pyw", "TEXT"),
+("Text files", "*.txt", "TEXT"),
  ("All files", "*"),
  ]

___
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] [Python-checkins] r86703 - python/branches/release31-maint/Lib/idlelib/IOBinding.py

[Senthil Kumaran]

Hi Terry,

On Tue, Nov 23, 2010 at 2:07 PM, terry.reedy  wrote:
> Author: terry.reedy
> Date: Tue Nov 23 07:07:04 2010
> New Revision: 86703
>
> Log:
> Issue 9222 Fix filetypes for open dialog
>
> Modified:
>   python/branches/release31-maint/Lib/idlelib/IOBinding.py


You should be using svnmerge.py script ( referenced in the dev FAQ),
to merge your changes to release31-maint. This helps in merge tracking
and helpful to release managers when they do the release.

It is pretty simple, in your release31-maint checkout:

Just run python svnmerge.py merge -r 9221 (your py3k revision value)
If successful, do a svn commit -F svnmerge-output-filename ( this file
is autogenerated)

If any conflicts occur, resolve them and then do the step 2.

Thanks,
Senthil
___
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] [Python-checkins] r86702 - python/branches/py3k/Lib/idlelib/IOBinding.py

[Georg Brandl]

Am 23.11.2010 07:13, schrieb Terry Reedy:
> 
> 
> On 11/23/2010 1:01 AM, terry.reedy wrote:
>> Author: terry.reedy
>> Date: Tue Nov 23 07:01:31 2010
>> New Revision: 86702
>>
>> Log:
> Issue 9222 Fix filetypes for open dialog
> 
> Sorry, forgot to add this before clicking [go] or whatever the button 
> is. Is there any way to revise a revision ;-?

Yes, with SVN there is.  I don't know if you can do it with whatever
GUI tool you use, but the command is the following:

svn propedit --revprop -r 86702 svn:log

In a short time however, after switching to Mercurial, commits will be
truly immutable.  However, since the equivalent to committing in SVN is
a two-step process (commit locally and then push one or more commits to
the public repo on the server), you can review your commits locally
before pushing them, and fix mistakes by "rewriting history" (you can
see from that description that it won't work when the changes are already
public).

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] [Python-checkins] r86703 - python/branches/release31-maint/Lib/idlelib/IOBinding.py

[Terry Reedy]

On 11/23/2010 1:16 AM, Senthil Kumaran wrote:

Hi Terry,

On Tue, Nov 23, 2010 at 2:07 PM, terry.reedy  wrote:

Author: terry.reedy
Date: Tue Nov 23 07:07:04 2010
New Revision: 86703

Log:
Issue 9222 Fix filetypes for open dialog

Modified:
   python/branches/release31-maint/Lib/idlelib/IOBinding.py



You should be using svnmerge.py script ( referenced in the dev FAQ),
to merge your changes to release31-maint. This helps in merge tracking
and helpful to release managers when they do the release.

It is pretty simple, in your release31-maint checkout:

Just run python svnmerge.py merge -r 9221 (your py3k revision value)
If successful, do a svn commit -F svnmerge-output-filename ( this file
is autogenerated)


I am using TortoiseSVN which has a similar merge but does not seem to 
autogenerate anything. I did use its merge + commit for the 2.7 backport.


Terry
___
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] Solaris family and 64 bits compiling

[Martin v. Löwis]

> But if we say the Python can be compiled as 64 bits under Solaris, would
> be nice if that was actually true. Now that we have a buildbot (under
> OpenIndiana) to test, it is doable.

But it is true, and always has been true. The lib/64 issue did not
prevent one building Python on Solaris/SPARC64 at all, including the
extension modules. Just edit Modules/Setup to suit your needs - that
works since 1995 (before distutils was even written).

> If not, we could say that Solaris+64 bits is unsupported. I don't think
> we should go that way. Solaris+64 bits should be a full citizen.

There we go again: "supported". Python builds on many systems which we
don't have buildbots for, including obscure systems (although Guido has
ruled that we won't specifically accept code for obscure systems
anymore, unlike we did before). It is never fully automatic (you always
have to at least make sure manually that the dependencies are
installed).

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] [Python-checkins] r86702 - python/branches/py3k/Lib/idlelib/IOBinding.py

[Terry Reedy]

On 11/23/2010 1:44 AM, Georg Brandl wrote:

Am 23.11.2010 07:13, schrieb Terry Reedy:



On 11/23/2010 1:01 AM, terry.reedy wrote:

Author: terry.reedy
Date: Tue Nov 23 07:01:31 2010
New Revision: 86702

Log:

Issue 9222 Fix filetypes for open dialog

Sorry, forgot to add this before clicking [go] or whatever the button
is. Is there any way to revise a revision ;-?


Yes, with SVN there is.  I don't know if you can do it with whatever
GUI tool you use, but the command is the following:

svn propedit --revprop -r 86702 svn:log

(followed by new message?)

OK, done. TortoiseSVN has a nice revision log dialog. Right click and 
one of the choices is 'edit log message'. Easy. I see that there is a 
TortoiseHg as well.


--
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