Re: [Python-Dev] PEP 384 final review

[Martin v. Löwis]

> I have now completed
> 
> http://www.python.org/dev/peps/pep-0384/
> 
> 
> was structseq.h considered?

No, it wasn't - unfortunately, it still doesn't get included when
including Python.h. I'll add it.

> IMO it could be made PEP384-compliant with two additions that would
> replace two non-compliant functions:
> 
> - A new function to create types, since PyStructSequence_InitType
> is supposed to work on a unititialized static variable:
> PyTypeObject *PyStructSequence_NewType(PyStructSequence_Desc *desc);
> - PyStructSequence_SetItem(), similar to the
> macro PyStructSequence_SET_ITEM; the PyStructSequence structure should
> be hidden.

Sounds good.

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 and the Unicode Character Database

[M.-A. Lemburg]

Alexander Belopolsky wrote:
> On Sun, Nov 28, 2010 at 5:42 PM, M.-A. Lemburg  wrote:
> ..
>> I don't see why the language spec should limit the wealth of number
>> formats supported by float().
>>
> 
> The Language Spec (whatever it is) should not, but hopefully the
> Library Reference should.  If you follow
> http://docs.python.org/dev/py3k/library/functions.html#float link and
> the references therein, you'll end up with

... the language spec again :-)

> digit  ::=  "0"..."9"
> 
> http://docs.python.org/dev/py3k/reference/lexical_analysis.html#grammar-token-digit

That's obviously a bug in the documentation, since the Python 2.7 docs
don't mention any such relationship to the language spec:

http://docs.python.org/library/functions.html#float

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 29 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] PEP 384 final review

[Georg Brandl]

Am 29.11.2010 09:09, schrieb "Martin v. Löwis":
>> I have now completed
>> 
>> http://www.python.org/dev/peps/pep-0384/
>> 
>> 
>> was structseq.h considered?
> 
> No, it wasn't - unfortunately, it still doesn't get included when
> including Python.h. I'll add it.

Would 3.2 be a good time to finally include it?  All of its macros and
declarations are named PyStructSequence*, so there shouldn't be a
name clash concern.

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] [Preview] Comments and change proposals on documentation

[Georg Brandl]

Am 28.11.2010 00:58, schrieb Steven D'Aprano:
> Georg Brandl wrote:
>> Am 27.11.2010 23:11, schrieb Steven D'Aprano:
> 
>>> I wasn't able to find a comment bubble that contained anything, so I 
>>> don't know what sort of information you expect them to contain -- every 
>>> one I tried said "0 comments".
>> 
>> Maybe you should have tried the page I recommended as a demo, and where Nick
>> made his comments? :)
> 
> Aha! I never would have guessed that the bubbles are clickable -- I 
> thought you just moused-over them and they showed static comments put 
> there by the developers, part of the documentation itself. I didn't 
> realise that it was for users to add spam^W comments to the page. With 
> that perspective, I need to rethink.
> 
> Yes, I failed to fully read the instructions you sent, or understand 
> them. That's what users do -- they don't read your instructions, and 
> they misunderstand them. If your UI isn't easily discoverable, users 
> will not be able to use it, and will be frustrated and annoyed. The user 
> is always right, even when they're doing it wrong *wink*

That's right, of course.  I really come to the conclusion that having a text
link that "looks like" a link, i.e. is underlined, will have a better UI
experience (since we cannot put notes "click bubble to comment" everywhere).

>>> But it seems to me that comments are superfluous, if not actively harmful:
>> 
>> (I've not read anything about harmful below.  Was that just FUD?)
> 
> Lowering accessibility to parts of the documentation is what I was 
> talking about when I said "actively harmful". But now that I have better 
> understanding of what the comment system is actually for, I have to rethink.

Thanks!

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] PEP 384 final review

[Matthias Klose]

On 29.11.2010 00:40, "Martin v. Löwis" wrote:

I have now completed

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

Benjamin has volunteered to rule on this PEP.

Please comment with any changes you want to see, or speak in
favor or against this PEP.


I looked at a diff with r84330 from the py3k branch.

Extensions built with Py_LIMITED_API have the python version encoded in it's 
name.  Which abi name should be used for these extensions?


 - The m and u modifiers in the abi name are complimentary (?)
 - debug builds and Py_LIMITED_API are incompatible (?) and therefore
   the current name should be used?
 - For posix systems the implementation is currently part of the abi name,
   are Py_LIMITED_API extensions supposed to be compatible with e.g. PyPy?
   Should the LIMITED_API abi name include the implementation string?
 - Should the distutils support for LIMITED_API be part of the pep, or
   be implemented later?

In favour of the pep.

  Matthias
___
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 and the Unicode Character Database

[M.-A. Lemburg]

Nick Coghlan wrote:
> On Mon, Nov 29, 2010 at 1:39 PM, Stephen J. Turnbull  
> wrote:
>> I agree that Python should make it easy for the programmer to get
>> numerical values of native numeric strings, but it's not at all clear
>> to me that there is any point to having float() recognize them by
>> default.
> 
> Indeed, as someone else suggested earlier in the thread, supporting
> non-ASCII digits sounds more like a job for the locale module than for
> the builtin types.
> 
> Deprecating non-ASCII support in the latter, while ensuring it is
> properly supported in the former sounds like a better way forward than
> maintaining the status quo (starting in 3.3 though, with the first
> beta just around the corner, we don't want to be monkeying with this
> in 3.2)

Since when do we only support certain Unicode features in specific
locales ?

If we would go down that road, we would also have to disable other
Unicode features based on locale, e.g. whether to apply non-ASCII
case mappings, what to consider whitespace, etc.

We don't do that for a good reason: Unicode is supposed to be
universal and not limited to a single locale.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 29 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] python3k : imp.find_module raises SyntaxError

[Sylvain Thénault]

On 25 novembre 11:22, Ron Adam wrote:
> On 11/25/2010 08:30 AM, Emile Anclin wrote:
> >
> >hello,
> >
> >working on Pylint, we have a lot of voluntary corrupted files to test
> >Pylint behavior; for instance
> >
> >$ cat /home/emile/var/pylint/test/input/func_unknown_encoding.py
> ># -*- coding: IBO-8859-1 -*-
> >""" check correct unknown encoding declaration
> >"""
> >
> >__revision__ = ''
> >
> >
> >and we try to find that module :
> >find_module('func_unknown_encoding', None). But python3 raises SyntaxError
> >in that case ; it didn't raise SyntaxError on python2 nor does so on our
> >func_nonascii_noencoding and func_wrong_encoding modules (with obvious
> >names)
> >
> >Python 3.2a2 (r32a2:84522, Sep 14 2010, 15:22:36)
> >[GCC 4.3.4] on linux2
> >Type "help", "copyright", "credits" or "license" for more information.
> from imp import find_module
> find_module('func_unknown_encoding', None)
> >Traceback (most recent call last):
> >   File "", line 1, in
> >SyntaxError: encoding problem: with BOM
> 
> I don't think there is a clear reason by design.  Also try importing
> the same modules directly and noting the differences in the errors
> you get.

IMO the point is that we can consider as a bug the fact that find_module
tries to somewhat read the content of the file, no? Though it seems to only
doing this for encoding detection or like since find_module doesn't choke on
a module containing another kind of syntax error.

So the question is, should we deal with this in pylint/astng, or can we expect
this to be fixed at some point?
-- 
Sylvain Thénault   LOGILAB, Paris (France)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure:   http://www.logilab.fr/services
CubicWeb, the semantic web framework:http://www.cubicweb.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] Python and the Unicode Character Database

[Nick Coghlan]

On Mon, Nov 29, 2010 at 9:02 PM, M.-A. Lemburg  wrote:
> If we would go down that road, we would also have to disable other
> Unicode features based on locale, e.g. whether to apply non-ASCII
> case mappings, what to consider whitespace, etc.
>
> We don't do that for a good reason: Unicode is supposed to be
> universal and not limited to a single locale.

Because parsing numbers is about more than just the characters used
for the individual digits. There are additional semantics associated
with digit ordering (for any number) and decimal separators and
exponential notation (for floating point numbers) and those vary by
locale. We deliberately chose to make the builtin numeric parsers
unaware of all of those things, and assuming that we can simply parse
other digits as if they were their ASCII equivalents and otherwise
assume a C locale seems questionable.

If the existing semantics can be adequately defined, documented and
defended, then retaining them would be fine. However, the language
reference needs to define the behaviour properly so that other
implementations know what they need to support and what can be chalked
up as being just an implementation accident of CPython. (As a point in
the plus column, both decimal.Decimal and fractions.Fraction were able
to handle the '١٢٣٤.٥٦' example in a manner consistent with the int
and float handling)

Regards,
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] PEP 384 final review

[Éric Araujo]

Hello,

> Please comment with any changes you want to see, or speak in
> favor or against this PEP.

How to get a diff between py3k and this branch?

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] PEP 384 final review

[Matthias Klose]

On 29.11.2010 14:14, Éric Araujo wrote:

Hello,


Please comment with any changes you want to see, or speak in
favor or against this PEP.


How to get a diff between py3k and this branch?


I used
svn diff svn://svn.python.org/python/branches/p...@84330 
svn://svn.python.org/python/branches/pep-0384

___
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] PEP 384 final review

[Nick Coghlan]

On Mon, Nov 29, 2010 at 11:37 PM, Matthias Klose  wrote:
> On 29.11.2010 14:14, Éric Araujo wrote:
>>
>> Hello,
>>
>>> Please comment with any changes you want to see, or speak in
>>> favor or against this PEP.
>>
>> How to get a diff between py3k and this branch?
>
> I used
> svn diff svn://svn.python.org/python/branches/p...@84330
> svn://svn.python.org/python/branches/pep-0384

I had to use the full read/write svn+ssh:python...@svn.python.org
repository URLs to get it to give me a diff. The http read only URLs
didn't work (no diff returned, just "svn: OPTIONS of
'http://svn.python.org/python/branches/pep-0384': 200 OK
(http://svn.python.org)"), and the bare svn protocol isn't enabled on
svn.python.org.

Since directory diffs don't appear to be enabled on the svn.python.org
ViewVC instance, it would probably be a good idea to put this up on
Reitveld so people can more easily see the details of what has been
changed on the branch to date. If nobody beats me to it, I'll put one
up in the morning.

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] PEP 384 final review

[Nick Coghlan]

On Mon, Nov 29, 2010 at 9:40 AM, "Martin v. Löwis"  wrote:
> I have now completed
>
> http://www.python.org/dev/peps/pep-0384/
>
> Benjamin has volunteered to rule on this PEP.
>
> Please comment with any changes you want to see, or speak in
> favor or against this PEP.

This is probably an issue independent of the PEP, but there appear to
be a *lot* of exposed typedefs for various type slots and other
function signatures that don't start with the Py prefix (i.e. getter,
setter, unaryfunc and friends). Python.h shouldn't be leaking
unprefixed names like that. We certainly shouldn't be enshrining them
in the stable ABI without adding prefixes first.

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 and the Unicode Character Database

[Antoine Pitrou]

On Mon, 29 Nov 2010 13:58:05 +1000
Nick Coghlan  wrote:
> On Mon, Nov 29, 2010 at 1:39 PM, Stephen J. Turnbull  
> wrote:
> > I agree that Python should make it easy for the programmer to get
> > numerical values of native numeric strings, but it's not at all clear
> > to me that there is any point to having float() recognize them by
> > default.
> 
> Indeed, as someone else suggested earlier in the thread, supporting
> non-ASCII digits sounds more like a job for the locale module than for
> the builtin types.

Not sure, really. For example, "\d" in a regular expression will match
all Unicode digits, unless you pass the re.ASCII flag. The C locale
mechanism generally does a poor job of supporting what MS seems to call
"culture-specific" characteristics.

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] Python and the Unicode Character Database

[Antoine Pitrou]

On Sun, 28 Nov 2010 21:32:15 -0500
Alexander Belopolsky  wrote:
> On Sun, Nov 28, 2010 at 6:43 PM, Steven D'Aprano  wrote:
> ..
> >> is more important than to assure users that once their program
> >> accepted some text as a number, they can assume that the text is
> >> ASCII.
> >
> > Seems like a pretty foolish assumption, if you ask me, pretty much akin to
> > assuming that if string.isalpha() returns true that string is ASCII.
> >
> 
> It is not to 99.9% of Python users whose code is written for 2.x.
> Their strings are byte strings and string.isdigit() does imply ASCII
> even if string.isalpha() does not in many locales.

We are not talking about string.isdigit(), we are talking about the
float() constructor when given an unicode string.  Constructing a float
from an unicode string is certainly a common thing, even in 2.x.

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] PEP 384 final review

[James Y Knight]

On Nov 29, 2010, at 8:58 AM, Nick Coghlan wrote:

> The http read only URLs
> didn't work (no diff returned, just "svn: OPTIONS of
> 'http://svn.python.org/python/branches/pep-0384': 200 OK
> (http://svn.python.org)"), 

That was the wrong url: you should've used 
http://svn.python.org/projects/python/branches/pep-0384

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 and the Unicode Character Database

[M.-A. Lemburg]

Nick Coghlan wrote:
> On Mon, Nov 29, 2010 at 9:02 PM, M.-A. Lemburg  wrote:
>> If we would go down that road, we would also have to disable other
>> Unicode features based on locale, e.g. whether to apply non-ASCII
>> case mappings, what to consider whitespace, etc.
>>
>> We don't do that for a good reason: Unicode is supposed to be
>> universal and not limited to a single locale.
> 
> Because parsing numbers is about more than just the characters used
> for the individual digits. There are additional semantics associated
> with digit ordering (for any number) and decimal separators and
> exponential notation (for floating point numbers) and those vary by
> locale. We deliberately chose to make the builtin numeric parsers
> unaware of all of those things, and assuming that we can simply parse
> other digits as if they were their ASCII equivalents and otherwise
> assume a C locale seems questionable.

Sure, and those additional semantics are locale dependent, even
between ASCII-only locales. However, that does not apply to the
basic building blocks, the decimal digits themselves.

> If the existing semantics can be adequately defined, documented and
> defended, then retaining them would be fine. However, the language
> reference needs to define the behaviour properly so that other
> implementations know what they need to support and what can be chalked
> up as being just an implementation accident of CPython. (As a point in
> the plus column, both decimal.Decimal and fractions.Fraction were able
> to handle the '١٢٣٤.٥٦' example in a manner consistent with the int
> and float handling)

The support is built into the C API, so there's not really much
surprise there.

Regarding documentation, we'd just have to add that numbers may
be made up of an Unicode code point in the category "Nd".

See http://www.unicode.org/versions/Unicode5.2.0/ch04.pdf, section
4.6 for details

"""
Decimal digits form a large subcategory of numbers consisting of those digits 
that can be
used to form decimal-radix numbers. They include script-specific digits, but 
exclude char-
acters such as Roman numerals and Greek acrophonic numerals. (Note that <1, 5> 
= 15 =
fifteen, but  = IV = four.) Decimal digits also exclude the compatibility 
subscript or
superscript digits to prevent simplistic parsers from misinterpreting their 
values in context.
"""

int(), float() and long() (in Python2) are such simplistic
parsers.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 29 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] PEP 384 final review

[Tarek Ziadé]

On Mon, Nov 29, 2010 at 11:24 AM, Matthias Klose  wrote:
> On 29.11.2010 00:40, "Martin v. Löwis" wrote:
>>
>> I have now completed
>>
>> http://www.python.org/dev/peps/pep-0384/
>>
>> Benjamin has volunteered to rule on this PEP.
>>
>> Please comment with any changes you want to see, or speak in
>> favor or against this PEP.
>
> I looked at a diff with r84330 from the py3k branch.
>
> Extensions built with Py_LIMITED_API have the python version encoded in it's
> name.  Which abi name should be used for these extensions?
>..
>  - Should the distutils support for LIMITED_API be part of the pep, or
>   be implemented later?

In any case, it has to be implemented in Distutils2, not in Distutils.
Distutils is frozen and just in maintenance mode.

Once Distutils2 final is released (it's currently in alpha), it will
be installable from 2.4 to 3.x and can provide this feature.

For Python itself we can backport the feature in its setup.py, until
Distutils2 is back to the sdtlib


> In favour of the pep.

+1

>
>  Matthias
>



-- 
Tarek Ziadé | http://ziade.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] [Preview] Comments and change proposals on documentation

[Alexander Belopolsky]

On Mon, Nov 29, 2010 at 3:52 AM, Georg Brandl  wrote:
..
>> Yes, I failed to fully read the instructions you sent, or understand
>> them. That's what users do -- they don't read your instructions, and
>> they misunderstand them. If your UI isn't easily discoverable, users
>> will not be able to use it, and will be frustrated and annoyed. The user
>> is always right, even when they're doing it wrong *wink*
>
> That's right, of course.  I really come to the conclusion that having a text
> link that "looks like" a link, i.e. is underlined, will have a better UI
> experience (since we cannot put notes "click bubble to comment" everywhere).
>
Please don't make comment bubbles more visible.  Doing so will only
decrease signal to noise ratio.  I think a little bit of a learning
barrier is a good thing: it will keep down the number of "Bart was
here" comments.
___
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 and the Unicode Character Database

[Alexander Belopolsky]

On Mon, Nov 29, 2010 at 2:22 AM, "Martin v. Löwis"  wrote:
>> The former ensures that literals in code are always readable; the later
>> allows users to enter numbers in their own number system. How could that
>> be a bad thing?
>
> It's YAGNI, feature bloat. It gives the illusion of supporting something
> that actually isn't supported very well (namely, parsing local number
> strings). I claim that there is no meaningful application
> of this feature.
>

Speaking of YAGNI, does anyone want to defend

>>> complex('١٢٣٤.٥٦j')
1234.56j

?

Especially given that we reject complex('1234.56i'):

http://bugs.python.org/issue10562
___
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 and the Unicode Character Database

[Antoine Pitrou]

On Mon, 29 Nov 2010 08:22:46 +0100
"Martin v. Löwis"  wrote:
> > The former ensures that literals in code are always readable; the later
> > allows users to enter numbers in their own number system. How could that
> > be a bad thing?
> 
> It's YAGNI, feature bloat. It gives the illusion of supporting something
> that actually isn't supported very well (namely, parsing local number
> strings). I claim that there is no meaningful application
> of this feature.

Still, if it's not detrimental and it it's not difficult to support,
then why do you care? You aren't even maintaining that part of the code.

I don't think "remove feature bloat" is part of our development goals
or practices. Given the diversity of our user base, such removal should
be done carefully and only for serious reasons.

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] Python and the Unicode Character Database

[M.-A. Lemburg]

Alexander Belopolsky wrote:
> On Mon, Nov 29, 2010 at 2:22 AM, "Martin v. Löwis"  wrote:
>>> The former ensures that literals in code are always readable; the later
>>> allows users to enter numbers in their own number system. How could that
>>> be a bad thing?
>>
>> It's YAGNI, feature bloat. It gives the illusion of supporting something
>> that actually isn't supported very well (namely, parsing local number
>> strings). I claim that there is no meaningful application
>> of this feature.

This is not about parsing local number strings, it's about
parsing number strings represented using different scripts -
besides en-US is a locale as well, ye know :-)

> Speaking of YAGNI, does anyone want to defend
> 
 complex('١٢٣٤.٥٦j')
> 1234.56j
> 
> ?

Yes. The same arguments apply.

Just because ASCII-proponents may have a hard time reading such
literals, doesn't mean that script users have the same trouble.

> Especially given that we reject complex('1234.56i'):
> 
> http://bugs.python.org/issue10562

We've had that discussion long before we had Unicode in Python.
The main reason was that 'i' looked to similar to 1 in a number
of fonts which is why it was rejected for Python source code.

However, I don't any reason why we shouldn't accept both i and
j for complex(), though, since the input to that constructor
doesn't have to originate in Python source code.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 29 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] python3k : imp.find_module raises SyntaxError

[Brett Cannon]

On Mon, Nov 29, 2010 at 03:53, Sylvain Thénault
 wrote:
> On 25 novembre 11:22, Ron Adam wrote:
>> On 11/25/2010 08:30 AM, Emile Anclin wrote:
>> >
>> >hello,
>> >
>> >working on Pylint, we have a lot of voluntary corrupted files to test
>> >Pylint behavior; for instance
>> >
>> >$ cat /home/emile/var/pylint/test/input/func_unknown_encoding.py
>> ># -*- coding: IBO-8859-1 -*-
>> >""" check correct unknown encoding declaration
>> >"""
>> >
>> >__revision__ = ''
>> >
>> >
>> >and we try to find that module :
>> >find_module('func_unknown_encoding', None). But python3 raises SyntaxError
>> >in that case ; it didn't raise SyntaxError on python2 nor does so on our
>> >func_nonascii_noencoding and func_wrong_encoding modules (with obvious
>> >names)
>> >
>> >Python 3.2a2 (r32a2:84522, Sep 14 2010, 15:22:36)
>> >[GCC 4.3.4] on linux2
>> >Type "help", "copyright", "credits" or "license" for more information.
>> from imp import find_module
>> find_module('func_unknown_encoding', None)
>> >Traceback (most recent call last):
>> >   File "", line 1, in
>> >SyntaxError: encoding problem: with BOM
>>
>> I don't think there is a clear reason by design.  Also try importing
>> the same modules directly and noting the differences in the errors
>> you get.
>
> IMO the point is that we can consider as a bug the fact that find_module
> tries to somewhat read the content of the file, no? Though it seems to only
> doing this for encoding detection or like since find_module doesn't choke on
> a module containing another kind of syntax error.
>
> So the question is, should we deal with this in pylint/astng, or can we expect
> this to be fixed at some point?

Considering these semantics changed between Python 2 and 3 w/o a
discernable benefit (I would consider it a negative as finding a
module should not be impacted by syntactic correctness; the full act
of importing should be the only thing that cares about that), I would
consider it a bug that should be filed.
___
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 and the Unicode Character Database

[Terry Reedy]

On 11/29/2010 10:19 AM, M.-A. Lemburg wrote:

Nick Coghlan wrote:

On Mon, Nov 29, 2010 at 9:02 PM, M.-A. Lemburg  wrote:

If we would go down that road, we would also have to disable other
Unicode features based on locale, e.g. whether to apply non-ASCII
case mappings, what to consider whitespace, etc.

We don't do that for a good reason: Unicode is supposed to be
universal and not limited to a single locale.


Because parsing numbers is about more than just the characters used
for the individual digits. There are additional semantics associated
with digit ordering (for any number) and decimal separators and
exponential notation (for floating point numbers) and those vary by
locale. We deliberately chose to make the builtin numeric parsers
unaware of all of those things, and assuming that we can simply parse
other digits as if they were their ASCII equivalents and otherwise
assume a C locale seems questionable.


Sure, and those additional semantics are locale dependent, even
between ASCII-only locales. However, that does not apply to the
basic building blocks, the decimal digits themselves.


If the existing semantics can be adequately defined, documented and
defended, then retaining them would be fine. However, the language
reference needs to define the behaviour properly so that other
implementations know what they need to support and what can be chalked
up as being just an implementation accident of CPython. (As a point in
the plus column, both decimal.Decimal and fractions.Fraction were able
to handle the '١٢٣٤.٥٦' example in a manner consistent with the int
and float handling)


The support is built into the C API, so there's not really much
surprise there.

Regarding documentation, we'd just have to add that numbers may
be made up of an Unicode code point in the category "Nd".

See http://www.unicode.org/versions/Unicode5.2.0/ch04.pdf, section
4.6 for details

"""
Decimal digits form a large subcategory of numbers consisting of those digits 
that can be
used to form decimal-radix numbers. They include script-specific digits, but 
exclude char-
acters such as Roman numerals and Greek acrophonic numerals. (Note that<1, 5>  
= 15 =
fifteen, but  = IV = four.) Decimal digits also exclude the compatibility 
subscript or
superscript digits to prevent simplistic parsers from misinterpreting their 
values in context.
"""

int(), float() and long() (in Python2) are such simplistic
parsers.


Since you are the knowledgable advocate of the current behavior, perhaps 
you could open an issue and propose a doc patch, even if not .rst formatted.


--
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] Python and the Unicode Character Database

[Alexander Belopolsky]

On Mon, Nov 29, 2010 at 1:33 PM, Antoine Pitrou  wrote:
> On Mon, 29 Nov 2010 08:22:46 +0100
> "Martin v. Löwis"  wrote:
>> > The former ensures that literals in code are always readable; the later
>> > allows users to enter numbers in their own number system. How could that
>> > be a bad thing?
>>
>> It's YAGNI, feature bloat. It gives the illusion of supporting something
>> that actually isn't supported very well (namely, parsing local number
>> strings). I claim that there is no meaningful application
>> of this feature.
>
> Still, if it's not detrimental and it it's not difficult to support,
> then why do you care?

It is difficult to support.  A fix for issue10557 would be much
simpler if we did not support non-European digits.  I now added a
patch that handles non-ascii digits, so you can see what's involved.
Note that when Unicode Consortium inevitably adds more Nd characters
to the non-BMP planes, we will have to add surrogate pairs' support to
this code.

In any case, there is little we can do about it in 3.2 other than fix
bugs like issue10557 without breaking currently valid code, so I
created a separate issue to continue this debate in context of 3.3.
[issue10581]

Now, I would like to bring this thread back to it's subject.  Given
that UCD is now affecting the language definition and the standard
library behavior, how should changes to UCD be handled?

- Should Python documentation refer to the specific version of Unicode
that it supports?

Current documentation refers to old versions.  Should version be
updated or removed to imply the latest?

- How UCD updates should be handled during the language moratorium?

During PEP 3003 discussion, it was suggested to handle it on a case by
case basis, but I don't see discussion of the upgrade to 6.0.0 in PEP
3003.  Should this upgrade be backported to 2.7?

- How specific should library reference manual be in defining methods
affected by UCD such as str.upper()?

- What is an acceptable level of variation between Python
implementations?  For example, if '\U'.isalpha() returns true
in one implementation, can it return false in another?  Note that even
CPython narrow and wide builds are presently not consistent in this
respect.


 [issue10581] http://bugs.python.org/issue10581
___
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 and the Unicode Character Database

[Alexander Belopolsky]

On Mon, Nov 29, 2010 at 2:23 PM, Terry Reedy  wrote:
..
> Since you are the knowledgable advocate of the current behavior, perhaps you
> could open an issue and propose a doc patch, even if not .rst formatted.
>

I am not an advocate of the current behavior, but an issue for doc patches is at
.
___
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] PEP 384 final review

[Martin v. Löwis]

>>  - Should the distutils support for LIMITED_API be part of the pep, or
>>   be implemented later?
> 
> In any case, it has to be implemented in Distutils2, not in Distutils.
> Distutils is frozen and just in maintenance mode.

I think it's too late for that. PEP 3149 is accepted, and it does
specify a change to distutils (namely, the abi= parameter). ISTM that
an approved PEP will override the distutils code freeze.

> For Python itself we can backport the feature in its setup.py, until
> Distutils2 is back to the sdtlib

This won't be for python itself, but for extension modules.

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] PEP 384 final review

[Tarek Ziadé]

2010/11/29 "Martin v. Löwis" :
>>>  - Should the distutils support for LIMITED_API be part of the pep, or
>>>   be implemented later?
>>
>> In any case, it has to be implemented in Distutils2, not in Distutils.
>> Distutils is frozen and just in maintenance mode.
>
> I think it's too late for that. PEP 3149 is accepted, and it does
> specify a change to distutils (namely, the abi= parameter). ISTM that
> an approved PEP will override the distutils code freeze.

Having an accepted PEP does not imply that it should be implemented in
the standard library.

For instance PEP 345 and PEP 376 are accepted but implemented in Distutils2.

it's also a:

- good opportunity to boost Distutils2 adoption
- way to get feedback from people for that abi= option and have the
chance to correct any design issue before d2 is added in the sdtlib


>
>> For Python itself we can backport the feature in its setup.py, until
>> Distutils2 is back to the sdtlib
>
> This won't be for python itself, but for extension modules.

ok.

>
> Regards,
> Martin
>



-- 
Tarek Ziadé | http://ziade.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] python3k : imp.find_module raises SyntaxError

[Ron Adam]

On 11/29/2010 01:22 PM, Brett Cannon wrote:

On Mon, Nov 29, 2010 at 03:53, Sylvain Thénault
  wrote:

On 25 novembre 11:22, Ron Adam wrote:

On 11/25/2010 08:30 AM, Emile Anclin wrote:


hello,

working on Pylint, we have a lot of voluntary corrupted files to test
Pylint behavior; for instance

$ cat /home/emile/var/pylint/test/input/func_unknown_encoding.py
# -*- coding: IBO-8859-1 -*-
""" check correct unknown encoding declaration
"""

__revision__ = ''


and we try to find that module :
find_module('func_unknown_encoding', None). But python3 raises SyntaxError
in that case ; it didn't raise SyntaxError on python2 nor does so on our
func_nonascii_noencoding and func_wrong_encoding modules (with obvious
names)

Python 3.2a2 (r32a2:84522, Sep 14 2010, 15:22:36)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>from imp import find_module

find_module('func_unknown_encoding', None)

Traceback (most recent call last):
   File "", line 1, in
SyntaxError: encoding problem: with BOM


I don't think there is a clear reason by design.  Also try importing
the same modules directly and noting the differences in the errors
you get.


IMO the point is that we can consider as a bug the fact that find_module
tries to somewhat read the content of the file, no? Though it seems to only
doing this for encoding detection or like since find_module doesn't choke on
a module containing another kind of syntax error.

So the question is, should we deal with this in pylint/astng, or can we expect
this to be fixed at some point?


Considering these semantics changed between Python 2 and 3 w/o a
discernable benefit (I would consider it a negative as finding a
module should not be impacted by syntactic correctness; the full act
of importing should be the only thing that cares about that), I would
consider it a bug that should be filed.


The output of imp.find_module() returns an open file io object, and it's 
output feeds directly into to imp.load_module().


>>> imp.find_module('pydoc')
(<_io.TextIOWrapper name=4 encoding='utf-8'>, 
'/usr/local/lib/python3.2/pydoc.py', ('.py', 'U', 1))


So I think the imp.find_module() is suppose to be used when you *do* want 
to do the full act of importing and not for just finding out if or where 
module xyz exists.



Ron



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 384 final review

[Martin v. Löwis]

> Extensions built with Py_LIMITED_API have the python version encoded in
> it's name.  Which abi name should be used for these extensions?

PEP 3149, IIUC, says it should be "abi3". I don't understand what that
means, though (with respect to, say, distutils)

>  - The m and u modifiers in the abi name are complimentary (?)

See above: none of these will be used. Of course, it is possible to name
an ABI-conforming extensions with the regular ABI name of the
Python release.

>  - For posix systems the implementation is currently part of the abi name,
>are Py_LIMITED_API extensions supposed to be compatible with e.g. PyPy?

That's a choice that PyPy needs to make, of course, but Amaury has
indicated that they are interested in doing so.

>Should the LIMITED_API abi name include the implementation string?
>  - Should the distutils support for LIMITED_API be part of the pep, or
>be implemented later?

Depends on what support you want. Currently, all you need to do is to
define Py_LIMITED_API to the preprocessor - this is something that is
already supported in distutils.

If you want the support suggested in PEP 3149 (specifying abi=3),
it should certainly be implemented in Python 3.2, despite the distutils
freeze.

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] PEP 384 final review

[Martin v. Löwis]

> This is probably an issue independent of the PEP but there appear to
> be a *lot* of exposed typedefs for various type slots and other
> function signatures that don't start with the Py prefix (i.e. getter,
> setter, unaryfunc and friends).

It's indeed independent: the names don't actually affect the ABI, but
the API. Changing them is possible later without risking binary
compatibility.

>  Python.h shouldn't be leaking
> unprefixed names like that. We certainly shouldn't be enshrining them
> in the stable ABI without adding prefixes first.

The stable ABI isn't actually enshrining them - what gets enshrined is
the value of the typedefs, not their names.

I don't mind renaming them, though. I see a number of different cases:

- struct names. I don't see a problem to have
  "typedef struct PyFoo PyFoo"
  I vaguely recall that there had been compiler problems with that
  construct at some point, but to my knowledge, they are past, and
  this is actually both well-formed C and well-formed C++.
- function pointer type names
- "various" other types

For the struct types, in particular for the ones which already have a
typedef, I think renaming them should be possible right away.
Applications that break should be able to use the typedef instead,
and continue to work with older releases.

For the function pointer type names, caution is necessary. We cannot
remove them, since it would break a lot of code. I also think that
some smart naming scheme would be desirable that makes the names all
sound right, yet allows easy mapping from the existing types. Once
such a scheme is added, we should have a graceful deprecation procedure,
such as:
- release A: add typedefs in addition to existing pointer types,
  deprecate pointer types in documentation
- release B>A: make the old names somehow conditional (e.g. put them
  all into a header file rename3.h, or some such)
- release C>B: remove rename3.h

For the other rest, I think many of them are considered internal (of
course, they shouldn't appear in the ABI then at all). Renaming them
right away might be fine.

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] PEP 384 final review

[Martin v. Löwis]

Am 29.11.2010 14:14, schrieb Éric Araujo:
> Hello,
> 
>> Please comment with any changes you want to see, or speak in
>> favor or against this PEP.
> 
> How to get a diff between py3k and this branch?

As others have already explained:

svn diff http://svn.python.org/projects/python/branches/p...@84329
http://svn.python.org/projects/python/branches/pep-0384

(84329 is the value of svnmerge-integrated).

In any case, I posted it to Rietveld as

http://codereview.appspot.com/3262043/

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] constant/enum type in stdlib

[Greg Ewing]

Rob Cliffe wrote:

But when a frozen list a.k.a. tuple would be created - either directly, 
or by setting a list's mutable flag to False which would really turn it 
into a tuple - the size *would* be known.


But at that point the object consists of two memory blocks -- one
containing just the object header and a pointer to the items, and
the other containing the items.

To turn that into a true tuple structure would require resizing
the main object block to be big enough to hold the items and
copying them into it. The main object can't be moved (because
there are PyObject *s all over the place pointing to it), so
if there's not enough room at its current location, you're out
of luck.

So lists frozen after creation would have to remain as two blocks,
making them second-class citizens compared to those that were
created frozen. Either that or store all lists/tuples as two
blocks, and give up some of the performance advantages of the
current tuple structure.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python and the Unicode Character Database

[Martin v. Löwis]

Am 29.11.2010 19:33, schrieb Antoine Pitrou:
> On Mon, 29 Nov 2010 08:22:46 +0100
> "Martin v. Löwis"  wrote:
>>> The former ensures that literals in code are always readable; the later
>>> allows users to enter numbers in their own number system. How could that
>>> be a bad thing?
>>
>> It's YAGNI, feature bloat. It gives the illusion of supporting something
>> that actually isn't supported very well (namely, parsing local number
>> strings). I claim that there is no meaningful application
>> of this feature.
> 
> Still, if it's not detrimental and it it's not difficult to support,
> then why do you care? You aren't even maintaining that part of the code.

I sure do maintain the Unicode database implementation in Python - the
one that is being used (IMO incorrectly) to implement the conversion in
question (and also the one that triggered this thread).

> I don't think "remove feature bloat" is part of our development goals
> or practices. Given the diversity of our user base, such removal should
> be done carefully and only for serious reasons.

I think it's a serious reason that the intuitive expectation of many
people (including committers) deviates from the actual implementation -
so much that they clarify the documentation in a way that makes the
difference explicit.

Having a mismatch between the expected behavior and the actual behavior
is a serious problem because it could lead to security issues, e.g. when
someone relies on float() to perform certain syntactic checking, making
it then possible to sneak in values that cause corruption later on
(speaking theoretically, of course - I'm not aware of an application
that is vulnerable in this manner).

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 and the Unicode Character Database

[Martin v. Löwis]

> - Should Python documentation refer to the specific version of Unicode
> that it supports?

You mean, mention it somewhere? Sure (although it would be nice if the
documentation generator would automatically extract it from the source,
just as it extracts the Python version number).

Of course, such mentioning should explain that this is specific to
CPython, and not an aspect of Python-the-language.

> Current documentation refers to old versions.  Should version be
> updated or removed to imply the latest?

What specific reference are you referring to?

> - How UCD updates should be handled during the language moratorium?

It's clearly not affected.

> During PEP 3003 discussion, it was suggested to handle it on a case by
> case basis, but I don't see discussion of the upgrade to 6.0.0 in PEP
> 3003.

It's covered by "As the standard library is not directly tied to the
language definition it is not covered by this moratorium."

>  Should this upgrade be backported to 2.7?

No, it's a new feature.

> - How specific should library reference manual be in defining methods
> affected by UCD such as str.upper()?

It should specify what this actually does in Unicode terminology
(probably in addition to a layman's rephrase of that)

> - What is an acceptable level of variation between Python
> implementations?  For example, if '\U'.isalpha() returns true
> in one implementation, can it return false in another?

Implementations are free to use any version of the UCD.

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] PEP 384 final review

[Martin v. Löwis]

Am 29.11.2010 09:36, schrieb Georg Brandl:
> Am 29.11.2010 09:09, schrieb "Martin v. Löwis":
>>> I have now completed
>>>
>>> http://www.python.org/dev/peps/pep-0384/
>>>
>>>
>>> was structseq.h considered?
>>
>> No, it wasn't - unfortunately, it still doesn't get included when
>> including Python.h. I'll add it.
> 
> Would 3.2 be a good time to finally include it?  All of its macros and
> declarations are named PyStructSequence*, so there shouldn't be a
> name clash concern.

Sure, I see no problem with that.

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] constant/enum type in stdlib

[Greg Ewing]

I don't see how the grouping can be completely separated
from the value-naming. If the named values are to be
subclassed from the base values, then you want all the
members of a group to belong to the *same* subclass.
You can't get that by treating each named value on its
own and then trying to group them together afterwards.

--
Greg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python and the Unicode Character Database

[Steven D'Aprano]

Alexander Belopolsky wrote:


Speaking of YAGNI, does anyone want to defend


complex('١٢٣٤.٥٦j')

1234.56j


*If* we allow float('١٢٣٤.٥٦') (as we currently do, but is being 
disputed by some), then we should allow complex('١٢٣٤.٥٦j'). It would be 
silly for complex to be more restrictive than float.




Especially given that we reject complex('1234.56i'):


I don't understand why you use 'i' when Python uses 'j' as the symbol 
for imaginary numbers.


>>> complex('1234.56j')
1234.56j

works fine. I have no problem with Python choosing one of i/j as the 
symbol for imaginary-1 and rejecting the other. I prefer i rather than 
j, but that's because my background is in maths rather than electrical 
engineering, but I can live with either.


But in any case, please don't conflate the question of whether Python 
should accept j and/or i for complex numbers with the question of 
supporting non-arabic numerals. The two issues are unrelated.




--
Steven

___
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] constant/enum type in stdlib

[Ron Adam]

On 11/28/2010 09:03 PM, Ron Adam wrote:


It does associate additional info to names and creates a nice dictionary to
reference.


 >>> def name_values( FOO: 1,
BAR: "Hello World!",
BAZ: dict(a=1, b=2, c=3) ):
... return FOO, BAR, BAZ
...
 >>> foo(1,2,3)
(1, 2, 3)
 >>> foo.__annotations__
{'BAR': 'Hello World!', 'FOO': 1, 'BAZ': {'a': 1, 'c': 3, 'b': 2}}


sigh... I havn't been very focused lately. That should have been:

>>> def named_values(FOO:1, BAR:"Hello World!", BAZ:dict(a=1, b=2, c=3)):
...   return FOO, BAR, BAZ
...
>>> named_values.__annotations__
{'BAR': 'Hello World!', 'FOO': 1, 'BAZ': {'a': 1, 'c': 3, 'b': 2}}
>>> named_values(1, 2, 3)
(1, 2, 3)

Cheers,
   Ron

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 384 final review

[Nick Coghlan]

On Tue, Nov 30, 2010 at 12:15 AM, James Y Knight  wrote:
>
> On Nov 29, 2010, at 8:58 AM, Nick Coghlan wrote:
>
> The http read only URLs
> didn't work (no diff returned, just "svn: OPTIONS of
> 'http://svn.python.org/python/branches/pep-0384': 200 OK
> (http://svn.python.org)"),
>
> That was the wrong url: you should've
> used http://svn.python.org/projects/python/branches/pep-0384
> James

Ah, thanks, I always forget that part (since it isn't there in the
read/write URLs).

The SVN output may qualify as one of the least helpful error messages
I have ever seen, though :)

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] constant/enum type in stdlib

[Nick Coghlan]

On Tue, Nov 30, 2010 at 7:36 AM, Greg Ewing  wrote:
> I don't see how the grouping can be completely separated
> from the value-naming. If the named values are to be
> subclassed from the base values, then you want all the
> members of a group to belong to the *same* subclass.
> You can't get that by treating each named value on its
> own and then trying to group them together afterwards.

Note that my sample implementation cached the created types, so that
(for example) there was only ever one "Named" type (my
implementation wasn't quite kosher in that respect, since
functools.lru_cache has a non-optional size limit - setting maxsize to
float('inf') deals with that). A grouping API would use either single
or multiple inheritance to create members that supported both the
naming aspects as well as the grouping aspects.

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 and the Unicode Character Database

[Alexander Belopolsky]

On Mon, Nov 29, 2010 at 5:09 PM, Steven D'Aprano  wrote:
..
> But in any case, please don't conflate the question of whether Python should
> accept j and/or i for complex numbers with the question of supporting
> non-arabic numerals. The two issues are unrelated.

The two issues are related because they are both about how strict
numerical constructors should be.   If we want to accept wide
variations in how numbers can be spelled, then surely using i for the
imaginary unit is much more common than using ७ for the digit 7.

I see two problems with supporting non-ascii spellings:

1. Support costs.

2. User confusion.

The two are related because when users are confused, they will report
invalid bugs when Python does not meet their expectations.  For
example, why


>>> int('１２３', 10)
123

works, but

>>> int('１２３ＡＢＣ', 16)
Traceback (most recent call last):
  ..
UnicodeEncodeError: 'decimal' codec can't encode character '\uff21' in
position 3: invalid decimal Unicode string

does not?  And if 'decimal' is a codec, why

>>> '123'.encode('decimal')
Traceback (most recent call last):
  ...
LookupError: unknown encoding: decimal

Before anyone suggests that int(.., 16) should consult the new
Hex_Digit property in the UCD, let me remind that int() supports bases
from 2 through 36.

I thought Python design was primarily driven by practicality.  Here
the only plausible argument that one can make is that if Unicode says
it is a digit, we should treat it as a digit.  Purity over
practicality.

In practical terms, UCD comes at a price.  The unicodedata module size
is over 700K on my machine.  This is almost half the size of the
python executable and by far the largest extension module. (only CJK
encodings come close.)  Making builtins depend on the largest
extension module for operation does not strike me as sound design.
___
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 and the Unicode Character Database

[Stephen J. Turnbull]

M.-A. Lemburg writes:

 > Just because ASCII-proponents may have a hard time reading such
 > literals,

That's not the point.

 > doesn't mean that script users have the same trouble.

The script users may have no trouble reading them, but that doesn't
mean it's not a YAGNI.  In Japanese, it's a YAGNI except in addresses
on New Year cards and in dates, which could be handled by specialized
modules, or by a generic module for extracting numeric information
from general (as opposed to program) text.  Neither of those is likely
to appear in program text in context where they would be used as a
numeric literal.

In fact, Python *does* consider it a YAGNI for Han!  Although my
apartment number would be written "七〇四" on a New Year card, Python
won't parse it as 704: unicodedata considers those digits to be Lo,
except for "〇" which fails anyway because it's Nl, not Nd.  (To add
insult to injury, it doesn't even return numeric values for those
characters, even though any Han-user would consider them numeric when
used in isolation, except that Japanese would be likely to consider
"〇" to be the non-numeric "maru" symbol, ie, circle, meaning "OK"!)

The whole concept of numeric in Unicode is a mess; why import that
mess into Python?

Can you give any examples where people do computation, keep books, or
do nuclear physics in non-Arabic numerals?  I suppose Arabic users
might, but even there I suspect not.

___
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 and the Unicode Character Database

[Stephen J. Turnbull]

Steven D'Aprano writes:

 > But in any case, please don't conflate the question of whether Python 
 > should accept j and/or i for complex numbers with the question of 
 > supporting non-arabic numerals. The two issues are unrelated.

Different, yes, unrelated, no.  They're both about whether variant
forms of universally used literals should be allowed in a programming
language, or whether only the canonical form is allowed.  Note that
*nobody* is saying that Python should have no facility for parsing
these numbers, only that by default literal decimal numerals should be
encoded as ASCII digits.

For example, I would not object to int() getting a Boolean flag
meaning "consult unicodedata for non-ASCII digits", just as it has an
optional parameter meaning "decode in base other than 10".[1]  OTOH,
until somebody says "Yes, in Mecca the bazaar traders keep books on
their Lenovos using ISO-8859-6 numerals, and it would be painful for
them to switch to what we call 'Arabic' numerals", I'm going to
consider it a YAGNI.  Just as even though mathematicians clearly
prefer "i" as the imaginary unit, there's not enough pain involved in
them switching to "j" to make it worth supporting both.

(BTW, my first reaction to the "j" notation was "cool, Python supports
quaternions out of the box!"  It took only a second or so to return to
reality, but that was my first reaction.)


Footnotes: 
[1]  That might not be a good idea on other grounds, but in principle
I would be OK with such built-ins accepting non-ASCII digits on
request.


___
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] PEP 291 versus Python 3

[Éric Araujo]

Good morning python-dev,

PEP 291 (Backward Compatibility for Standard Library) does not seem to
take Python 3 into account.  Is this PEP only relevant for the 2.7
branch?*  If it’s supposed to apply to 3.x too, despite the view that
3.0 was a clean break, what does it mean to have a module that is
developed in the py3k branch and should retain compatibility with 2.3 or
1.5.2?

* Tarek’s interpretation: “The 2.x needs to stay 2.3 compatible
  so we should keep the 3.x as similar as possible for bugfixes.”

In the particular case of distutils (should be compatible with 2.3), we
(including I) have been lax.  Our tests for example use modern unittest
features like skips, which makes them not runnable on old Pythons.  I am
very uncomfortable with code that seems to run fine but which tests
(however few) cannot be run, so I think I’ll have to trade the skips for
old-style “return” statements.  The other way of solving that is to
change the compat policy.  If I remember correctly, the rationale for
code compat in distutils is that people may copy distutils from Python
x.y to their install of x.y-n; I don’t know if this is still an active
practice, and if it is, I don’t know if it should be supported,
considering that distutils2 (compatible with 2.4+ and available from
PyPI) is coming.

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