Re: [Python-Dev] Point of building without threads?

2012-05-08 Thread Kristján Valur Jónsson 


> 
> I guess a long time ago, threading support in operating systems wasn't very
> widespread, but these days all our supported platforms have it.
> Is it still useful for production purposes to configure --without-threads? Do
> people use this option for something else than curiosity of mind?

For EVE Online, we started out not using threads but relying solely on tasklets.
We only added thread supports perhaps five years ago.  Other embedded projects 
_might_ be omitting thread support for a leaner interpreter, but I'm not sure 
the difference is that large.
K

___
Python-Dev mailing list
[email protected]
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 405 (pyvenv) and system Python upgrades

2012-05-08 Thread Vinay Sajip 
Carl Meyer  oddbird.net> writes:

> The "version" key could in theory be useful to know whether a particular 
> venv created by that Python has or has not yet been upgraded to match, 
> but since the upgrade is trivial and idempotent I don't think that is 
> important.

Agreed it's not essential, but it also provides some useful information about
the version (for a user, rather than the update script) without actually having
to invoke the interpreter to check.

Regards,

Vinay Sajip

___
Python-Dev mailing list
[email protected]
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 3.3 cannot find BeautifulSoup but Python 3.2 can

2012-05-08 Thread Brett Cannon 
This really isn't the right mailing list to ask this kind of question (I
know you got help last time with your Debian-specific problem, but that was
because people got overly excited =). Python-dev is meant for discussing
the development *of* Python, not using it or developing *with* it.

I would try your question on comp.lang.python/python-list.

On Sun, May 6, 2012 at 7:28 PM, Edward C. Jones wrote:

> I use up-to-date Debian testing (wheezy), amd64 architecture.  I compiled
> and installed Python 3.3.0 alpha 3 using "altinstall".  Debian wheezy comes
> with python3.2 (and 2.6 and 2.7).  I installed the Debian package
> python3-bs4 (BeautifulSoup).  I also downloaded a "clone" developmental
> copy of 3.3.
>
> Python3.3a3 cannot find module bs4.  Neither can the "clone".  Python3.2
> can find
> the module.  Here is a session with the "clone":
>
> > ./python
> Python 3.3.0a3+ (default:10ccbb90a8e9, May  6 2012, 19:11:02)
> [GCC 4.6.3] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import bs4
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "", line 974, in _find_and_load
> ImportError: No module named 'bs4'
> [71413 refs]
> >>>
>
> What is the problem?
>
>
> __**_
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> brett%40python.org
>
___
Python-Dev mailing list
[email protected]
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 3.3 cannot find BeautifulSoup but Python 3.2 can

2012-05-08 Thread Barry Warsaw 
On May 08, 2012, at 11:13 AM, Brett Cannon wrote:

>This really isn't the right mailing list to ask this kind of question (I
>know you got help last time with your Debian-specific problem, but that was
>because people got overly excited =). Python-dev is meant for discussing
>the development *of* Python, not using it or developing *with* it.
>
>I would try your question on comp.lang.python/python-list.

There are lots of good resources for Debian-specific Python issues (mailing
lists, IRC, etc.).  Start here:

http://wiki.debian.org/Python

Cheers,
-Barry
___
Python-Dev mailing list
[email protected]
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 405 (pyvenv) and system Python upgrades

2012-05-08 Thread Carl Meyer 

Hi Paul,

On 05/07/2012 04:16 PM, Paul Moore wrote:

On 7 May 2012 21:55, "Martin v. Löwis"  wrote:

This sounds to me like a level of complexity unwarranted by the severity
of the problem, especially when considering the additional burden it
imposes on alternative Python implementations.



OTOH, it *significantly* reduces the burden on Python end users, for
whom creation of a venv under a privileged account is a significant
hassle.


Personally, I would find a venv which required being run as an admin
account to be essentially unusable on Windows (particularly Windows 7,
where this means creating venvs in an "elevated" console window).

Allowing for symlinks as an option is fine, I guess, but I'd be -1 on
it being the default.


I don't think anyone has proposed making symlinks the default on 
Windows. At this point the two options on Windows would be to use the 
--symlink option explicitly, or else to need to run "pyvenv --upgrade" 
on your envs if you upgrade the underlying Python in-place (and there's 
a breaking incompatibility between the new stdlib and the old 
interpreter, which there almost never will be if the past is any 
indication).


I expect most users will opt for the latter option (equivalent to how 
current virtualenv works, except virtualenv doesn't have an --upgrade 
flag so you have to upgrade manually), but the former is also available 
if some prefer it.


In any case, the situation will be no worse than it is with virtualenv 
today.


Carl
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-08 Thread Barry Warsaw 
On May 08, 2012, at 11:59 AM, Nick Coghlan wrote:

>No, the "mcl" in the call is just the designated metaclass - the
>*actual* metaclass of the resulting class definition may be something
>different. That's why this is a separate method from mcl.__new__.

I'm not completely sold on adding a class method to type, but I acknowledge
that it's a convenient place to put it.  Still, it doesn't feel particularly
more right than adding it to say, the operator module.  I don't think we have
any class methods on type yet, so this would be setting a precedence that we
should be sure we want to establish.

Cheers,
-Barry
___
Python-Dev mailing list
[email protected]
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 405 (pyvenv) and system Python upgrades

2012-05-08 Thread Paul Moore 
On 8 May 2012 17:14, Carl Meyer  wrote:
> I don't think anyone has proposed making symlinks the default on Windows. At
> this point the two options on Windows would be to use the --symlink option
> explicitly, or else to need to run "pyvenv --upgrade" on your envs if you
> upgrade the underlying Python in-place (and there's a breaking
> incompatibility between the new stdlib and the old interpreter, which there
> almost never will be if the past is any indication).
>
> I expect most users will opt for the latter option (equivalent to how
> current virtualenv works, except virtualenv doesn't have an --upgrade flag
> so you have to upgrade manually), but the former is also available if some
> prefer it.
>
> In any case, the situation will be no worse than it is with virtualenv
> today.

That sounds fine. I apologise - I'd got the impression that the
proposal was to make symlinks the default.

Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Point of building without threads?

2012-05-08 Thread Stefan Krah 
Antoine Pitrou  wrote:
> I guess a long time ago, threading support in operating systems wasn't
> very widespread, but these days all our supported platforms have it.
> Is it still useful for production purposes to configure
> --without-threads? Do people use this option for something else than
> curiosity of mind?

_decimal is about 12% faster without threads, because the expensive
thread local context can be disabled.

On OpenBSD threading leads to strange problems like delayed signals
in the REPL http://bugs.python.org/issue8714 . Without threads these
problems don't occur.



Stefan Krah



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

Re: [Python-Dev] c/ElementTree XML serialisation

2012-05-08 Thread Alex Leach 
Furthermore, if I use the "html" method (an option given to 
ElementTree.write), closing tags are converted to lower case, which leads to 
an XML parsing error with camel-cased tag names.
Using the "text" method instead removes all tags, and I get a ValueError if I 
try to use the "c14n" method.

This seems like a limitation in ElementTree.py only, as _elementtree.c doesn't 
appear to contain any of these serialization or writing methods.

What I think I'll do is write a _serialise_svg function and add it to the 
_serialize dictionary of function lookups, from the module I'm working on. 
That way I hope I can pass method="svg" to ElementTree's write() method; it 
should work, and it should also be backwards-compatible.

That should be quite a quick and easy fix actually. Would this be something 
worth incorporating into ElementTree downstream?

Kind regards,
Alex


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

Re: [Python-Dev] Point of building without threads?

2012-05-08 Thread Antoine Pitrou 
On Tue, 8 May 2012 19:40:32 +0200
Stefan Krah  wrote:
> Antoine Pitrou  wrote:
> > I guess a long time ago, threading support in operating systems wasn't
> > very widespread, but these days all our supported platforms have it.
> > Is it still useful for production purposes to configure
> > --without-threads? Do people use this option for something else than
> > curiosity of mind?
> 
> _decimal is about 12% faster without threads, because the expensive
> thread local context can be disabled.

If you cached the last thread id along with the corresponding context,
perhaps it could speed things up in most scenarios?

Regards

Antoine.


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

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-08 Thread Terry Reedy 

On 5/8/2012 12:50 PM, Barry Warsaw wrote:

On May 08, 2012, at 11:59 AM, Nick Coghlan wrote:


No, the "mcl" in the call is just the designated metaclass - the
*actual* metaclass of the resulting class definition may be something
different. That's why this is a separate method from mcl.__new__.


I'm not completely sold on adding a class method to type, but I acknowledge
that it's a convenient place to put it.  Still, it doesn't feel particularly
more right than adding it to say, the operator module.


The operator module strikes me as completely wrong. To me, a function 
that creates classes (types) belongs either in the types module or 
attached to the type metaclass. Attaching an alternate constructor to 
type as a class method would be analogous to attaching an alternate dict 
constructor to dict (.fromkeys).


--
Terry Jan Reedy

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

Re: [Python-Dev] c/ElementTree XML serialisation

2012-05-08 Thread Terry Reedy 

On 5/8/2012 12:21 PM, Alex Leach wrote:


Is there a better way?


This really looks like a python-list question. I don't see that it has 
much to do with developing 3.3. (any more than most pythonl-list questions.)


--
Terry Jan Reedy

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

Re: [Python-Dev] c/ElementTree XML serialisation

2012-05-08 Thread And Clover 

On 08/05/12 17:21, Alex Leach wrote:
> The w3c SVG specification / recommendation
>   allows for

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-08 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2012 09:59 PM, Nick Coghlan wrote:
> On Mon, May 7, 2012 at 11:42 PM, Hrvoje Niksic 
> wrote:
>> On 05/07/2012 02:15 PM, Nick Coghlan wrote:
>>> 
>>> Benjamin's suggestion of a class method on type may be a good
>>> one, though. Then the invocation (using all arguments) would be:
>>> 
>>> mcl.build_class(name, bases, keywords, exec_body)
>>> 
>>> Works for me, so unless someone else can see a problem I've
>>> missed, we'll go with that.
>> 
>> 
>> Note that to call mcl.build_class, you have to find a metaclass that
>> works for bases, which is the job of build_class.  Putting it as a
>> function in the operator module seems like a better solution.
> 
> No, the "mcl" in the call is just the designated metaclass - the 
> *actual* metaclass of the resulting class definition may be something 
> different. That's why this is a separate method from mcl.__new__.

Why not make it a static method, if there is no notion of a useful 'cls'
argument?


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  [email protected]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+poCQACgkQ+gerLs4ltQ6IUwCfckUDbCCFjRPcFtvQmTXUcGuv
8RYAoKzry9l0xB7G+I0fIBqAp+3DJTdc
=3kdb
-END PGP SIGNATURE-

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

Re: [Python-Dev] c/ElementTree XML serialisation

2012-05-08 Thread Alex Leach 
On Tuesday 08 May 2012 23:15:43 And Clover wrote:
| 
| CDATA sections are of use for hand-authoring readability, but don't help
| in machine-serialised documents. You don't get away from the need to
| encode out-of-band sequences (notably ]]> is still invalid) so it
| doesn't buy you any simplicity.

It's not simplicity I'm looking for but functionality. I did initially make a 
true XML generator (no javascript or CSS intended or included), but including 
a small ecmascript rather than 500,000 separate x and y co-ordinates made the 
SVG about 28MB simpler, so I'm ahead already. The current XML generator can't 
be used to write javascript stored within any Element because it forcefully 
substitutes >, < and & for their HTML counterparts.

| 
|  > it's definitely a problem when generating SVG
| 
| No, not really. Neither XML nor SVG mandate use of CDATA sections here;
| a normal XML-encoded text node as produced by _serialize_xml is fine,
| and works with all XML processing tools.

Maybe the script block doesn't require CDATA wrappers, but style blocks 
without them don't work, at least in firefox. Perhaps even worse, vim 
highlighting breaks too!

Quoting: http://www.w3.org/TR/SVG/styling.html#StylingWithCSS

"""Note how the CSS style sheet is placed within a CDATA construct (i.e., ). Placing internal CSS style sheets within CDATA blocks is 
sometimes necessary since CSS style sheets can include characters, such as 
">", which conflict with XML parsers. Even if a given style sheet does not use 
characters that conflict with XML parsing, it is highly recommended that 
internal style sheets be placed inside CDATA blocks."""

| 
| HTML serialisation has custom rules (the two CDATA elements) because the
| HTML syntax is not XML. XML languages (including SVG and non-legacy
| served-as-XML XHTML) have no such special cases.

True. I might not need the CDATA tag to wrap the javascript then, but I still 
need < and > symbols. I have no idea how to write a loop in javascript without 
one.

| 
| (There are other problems in ElementTree's serialiser that make the
| output unreflective of the infoset in certain cases, but not here.)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages

2012-05-08 Thread Matthias Klose 
On 05.05.2012 16:13, Antoine Pitrou wrote:
> On Sat, 05 May 2012 16:04:40 +0200
> Christian Heimes  wrote:
>> Am 05.05.2012 15:39, schrieb Antoine Pitrou:
>>> On Sat, 05 May 2012 15:31:24 +0200
>>> Christian Heimes  wrote:
 Am 05.05.2012 12:36, schrieb Antoine Pitrou:
>
> Hello,
>
> On Fri, 04 May 2012 14:07:28 -0400
> "Edward C. Jones"  wrote:
>> Filelist of package libbz2-dev in wheezy of architecture amd64
>>
>> /usr/include/bzlib.h
>> /usr/lib/x86_64-linux-gnu/libbz2.a
>> /usr/lib/x86_64-linux-gnu/libbz2.so
>> /usr/share/doc/libbz2-dev
>
> setup.py probably doesn't search in the right paths for libbz2.so. I
> suggest you open a bug at http://bugs.python.org

 The issue might be caused by Debian's new multiarch libraries. In recent
 versions of Debian (and Ubuntu), 64bit and 32bit libraries can coexist
 on the same system.
>>>
>>> It probably is, but I thought Barry had tackled that in setup.py :-)
>>
>> The fix needs the dpkg-architecture program. As Tshepang pointed out it
>> may not be available on Edward's box. I always install build-essential
>> on all development boxes as it includes GCC, make and dpkg-dev.
> 
> Perhaps setup.py should detect that? It shouldn't be too hard to
> parse /etc/debian_version in order to know whether the system is
> multiarch-enabled. That would avoid confusing build failures.

IMO, the correct fix would be not to hard-code the system include and library
directories, but get them from gcc directly (if CC is gcc), and not relying on
dpkg-architecture.

$ gcc -v -E -  search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/4.6/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
[...]
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../:/lib/:/usr/lib/

  Matthias
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-08 Thread Nick Coghlan 
On Wed, May 9, 2012 at 8:37 AM, Tres Seaver  wrote:
>> No, the "mcl" in the call is just the designated metaclass - the
>> *actual* metaclass of the resulting class definition may be something
>> different. That's why this is a separate method from mcl.__new__.
>
> Why not make it a static method, if there is no notion of a useful 'cls'
> argument?

We need the explicitly declared metaclass as well as the bases in
order to determine the correct metaclass.

As a static method, the invocation would look like:

type.build_class(mcl, bases, keywords, exec_body)

Since mcl will always be an instance of type in 3.x (due to all
classes being subtypes of object), it makes more sense to just make it
a class method and invoke the method on the declared metaclass:

mcl.build_class(bases, keywords, exec_body)

The following assertion *does not* hold reliably:

cls = mcl.build_class(bases, keywords, exec_body)
assert type(cls) == mcl # Not guaranteed

Instead, the invariant that holds is the weaker assertion:

cls = mcl.build_class(bases, keywords, exec_body)
assert isinstance(cls, mcl)

This is due to the fact that one of the bases may specify that the
actual metaclass is a subtype of mcl rather than mcl itself.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-08 Thread Barry Warsaw 
Hi Eric,

Great job on the latest PEP 421.  I really like it.  A few additional
comments/questions.

 * sys.implementation.version

   This is defined as the version of the implementation, while
   sys.version_info is the version of the language.  The semantics of
   sys.version_info have been sufficiently squishy in the past, as the XXX
   implies.  This PEP shouldn't try to untangle that, so I think it be better
   to represent both values explicitly in sys.implementation.

 * Adding new required variables.  I'd claim that it's not unduly heavyweight
   to require a new PEP to add required variables to sys.implementation.  That
   hypothetical PEP will have to include things like rationale, impact on
   other implementations, etc.  That seems like enough to warrant a new PEP,
   even if it's relatively succinct.

   I'd also make it clear that adding new variables to
   sys.implementation.metadata explicitly does *not* require a PEP.

 * In Example Metadata Value:

   "If they later have meaningful uses cases, they can be added by following
   the process described in Adding New Required Attributes."

   I'd rephrase this to "If these or any other variables are deemed to have
   meaningful use cases across all implementations, they can be moved or added
   to sys.implementation directly, following the process described in Adding
   New Required Attributes."

 * I mildly prefer sys.implementation.name to be lower cased.  My intuition is
   that to be safe, most comparisons of the value will coerce to lower case,
   which is easy enough in Python, but perhaps a bit more of a pain in C.  I
   don't feel really strongly about this though.  (A counter argument is that
   the value might be printed, so a case-sensitive version would be better.)

 * Since I'm advocating to be explicit about the language version and the
   implementation version, .hexversion is probably also useful for both.

 * I've said before that I think the keys in sys.implementation should be
   locked down (i.e. not writable).  I think sys.implementation.metadata
   should be the same type.

Cheers,
-Barry



signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages

2012-05-08 Thread Barry Warsaw 
On May 09, 2012, at 02:17 AM, Matthias Klose wrote:

>IMO, the correct fix would be not to hard-code the system include and library
>directories, but get them from gcc directly (if CC is gcc), and not relying on
>dpkg-architecture.
>
>$ gcc -v -E - [...]
>#include <...> search starts here:
> /usr/lib/gcc/x86_64-linux-gnu/4.6/include
> /usr/local/include
> /usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed
> /usr/include/x86_64-linux-gnu
> /usr/include
>End of search list.
>[...]
>LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../:/lib/:/usr/lib/

+1

This would make a good fix for Python 3.3.  Matthias, perhaps you can work up
a patch for that?

-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-08 Thread Eric Snow 
On Tue, May 8, 2012 at 7:14 PM, Barry Warsaw  wrote:
> Hi Eric,
>
> Great job on the latest PEP 421.  I really like it.

Encouragement appreciated.  :)

>  A few additional
> comments/questions.
>
>  * sys.implementation.version
>
>   This is defined as the version of the implementation, while
>   sys.version_info is the version of the language.  The semantics of
>   sys.version_info have been sufficiently squishy in the past, as the XXX
>   implies.  This PEP shouldn't try to untangle that, so I think it be better
>   to represent both values explicitly in sys.implementation.

Definitely tangled.  So, sys.implementation.version and
sys.implementation.lang_version?  Also, my inclination is to not have
a sys.version equivalent in sys.implementation for now, in the
interest of keeping things as bare-bones as possible to start.

>  * Adding new required variables.  I'd claim that it's not unduly heavyweight
>   to require a new PEP to add required variables to sys.implementation.  That
>   hypothetical PEP will have to include things like rationale, impact on
>   other implementations, etc.  That seems like enough to warrant a new PEP,
>   even if it's relatively succinct.

Agreed.  I'll go with that for the PEP.

>   I'd also make it clear that adding new variables to
>   sys.implementation.metadata explicitly does *not* require a PEP.

Good point.

>  * In Example Metadata Value:
>
>   "If they later have meaningful uses cases, they can be added by following
>   the process described in Adding New Required Attributes."
>
>   I'd rephrase this to "If these or any other variables are deemed to have
>   meaningful use cases across all implementations, they can be moved or added
>   to sys.implementation directly, following the process described in Adding
>   New Required Attributes."

That's an important distinction.  I'll clean it up.

>  * I mildly prefer sys.implementation.name to be lower cased.  My intuition is
>   that to be safe, most comparisons of the value will coerce to lower case,
>   which is easy enough in Python, but perhaps a bit more of a pain in C.  I
>   don't feel really strongly about this though.  (A counter argument is that
>   the value might be printed, so a case-sensitive version would be better.)

I'm not sure it makes a lot of difference.  Since cache_tag will be
provided by the implementation, I don't have any strong use-cases that
would constrain the name itself.  Still, my preference is for lower
case as well.  I'll mull this one over.

>  * Since I'm advocating to be explicit about the language version and the
>   implementation version, .hexversion is probably also useful for both.

That's fine with me, and pretty trivial to do.

>  * I've said before that I think the keys in sys.implementation should be
>   locked down (i.e. not writable).

I've been on and off about this.  It's certainly not too hard to do,
it makes sense, and I don't see a lot of reason not to do it.  I'll
give it a go.

> I think sys.implementation.metadata
>   should be the same type.

This I wonder about.  The more I think about it, the more it fits.
I'll give it a day and if that still holds I'll work it in.

Thanks for the feedback, Barry!  Feels like the PEP's getting close.

-eric
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] c/ElementTree XML serialisation

2012-05-08 Thread Xavier Morel 

On 2012-05-09, at 01:41 , Alex Leach wrote:
> 
> True. I might not need the CDATA tag to wrap the javascript then, but I still 
> need < and > symbols. I have no idea how to write a loop in javascript 
> without 
> one.

Erm… you have them? What do you think `<` and `>` are?

As to writing a loop in javascript without < and >, == and != generally
work rather well, as does Array.prototype.forEach[0]

[0] 
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/forEach
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-08 Thread Daniel Urban 
On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan  wrote:
> On Wed, May 9, 2012 at 8:37 AM, Tres Seaver  wrote:
>>> No, the "mcl" in the call is just the designated metaclass - the
>>> *actual* metaclass of the resulting class definition may be something
>>> different. That's why this is a separate method from mcl.__new__.
>>
>> Why not make it a static method, if there is no notion of a useful 'cls'
>> argument?
>
> We need the explicitly declared metaclass as well as the bases in
> order to determine the correct metaclass.

Note, that the current patch (at http://bugs.python.org/issue14588)
obtains the explicitly declared metaclass from the keywords dict
(exactly like the class statement).

> As a static method, the invocation would look like:
>
>    type.build_class(mcl, bases, keywords, exec_body)

So I think, that in theory, this static method could work exactly like
the operator.build_class function in the patch: type.build_class(name,
bases, kwds, exec_body) (it doesn't need the mcls in a separate
argument, it is in kwds).

> Since mcl will always be an instance of type in 3.x (due to all
> classes being subtypes of object), it makes more sense to just make it
> a class method and invoke the method on the declared metaclass:
>
>    mcl.build_class(bases, keywords, exec_body)

We could do that, but "mcl will always be an instance of type in 3.x"
is not strictly true: an arbitrary callable is still allowed as a
metaclass in a class statement, so I think the build_class function
should support it too.

> The following assertion *does not* hold reliably:
>
>    cls = mcl.build_class(bases, keywords, exec_body)
>    assert type(cls) == mcl # Not guaranteed

Right.

> Instead, the invariant that holds is the weaker assertion:
>
>    cls = mcl.build_class(bases, keywords, exec_body)
>    assert isinstance(cls, mcl)

But if mcl is an arbitrary callable, this is also not always true (of
course, then the invocation above wouldn't work, but with a class
statement we could still create such "classes":

>>> def f(mcls, name, bases):
... return 0
...
>>> class C(metaclass=f):
... pass
...
>>> C
0


Daniel
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com