Re: [Python-Dev] Announcing PEP 3136
This thread moved to python-ideas so please post only there. http://mail.python.org/pipermail/python-ideas/2009-October/005924.html --yuv ___ 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] eggs now mandatory for pypi?
David Lyon wrote: > Distutils for windows is very, very dead.. grave-ware in-fact. Now that is not true at all. We have a native Windows installer (bdist_wininst) and an MSI builder (bdist_msi) that both work great on Windows. Plus there are add-ons for other installers such as NSIS and InnoSetup. Please don't forget that setuptools is not distutils, it's just a package extending distutils. If you find bugs related to Windows, please file a bug report. If you have specific proposals for distutils on Windows, you can use the mailing list or send patches to the tracker. The ham/egg ratio on the mailing list tends to be very much on the egg side, so the tracker can help get more attention from folks doing distutils without setuptools. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 07 2009) >>> 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 [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] transitioning from % to {} formatting
2009/10/4 INADA Naoki :
> What about using string prefix 'f'?
>
> f"{foo} and {bar}" % something == "{foo} and {bar}.format(something)
>
> s = f"{foo}"
> t = "%(bar)s"
> s + t # raises Exception
>
> Transition plan:
> n: Just add F prefix. And adding "format_string" in future.
> n+1: deprecate __mod__() without 'F'.
> n+2: libraries use .format() and deprecate __mod__() with 'F'
> n+3: remove __mod__()
-1 That requires keeping formatting information around in every string instance.
--
Regards,
Benjamin
___
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 389: argparse - new command line parsing module
Paul Moore wrote: Traceback (most recent call last): File "hello.py", line 13, in main() File "hello.py", line 7, in main sys.stdout.flush() IOError: [Errno 9] Bad file descriptor (Question - is it *ever* possible for a Unix program to have invalid file descriptors 0,1 and 2? At startup - I'm assuming anyone who does os.close(1) knows what they are doing!) Of course; simply use the >&- pseudo-redirection, which has been a standard sh feature (later inherited by ksh and bash, but not csh) for ~30 years. The error message is amusing, too: $ python -c 'print "foo"' >&- close failed in file object destructor: Error in sys.excepthook: Original exception was: Adding an explicit flush results in a more understandable error message: Traceback (most recent call last): File "", line 1, in IOError: [Errno 9] Bad file descriptor ___ 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
[Python-Dev] Python byte-compiled and optimized code
I am working on deploying Python on VxWorks platform as a part of project for my company. Accordingly, I would like to know couple of things from python's core-developers. Although I think I already know the answers for most of the questions, we need a confirmation from the community 1) Is the byte-compiled .pyc file and optimized .pyo file platform-independent?(including python versions 3.x) *If yes, is it guaranteed to stay that way in future?* 2) If the the generation of .pyc file fails (say, due to write protected area), does that stop the script execution? 3) Is it possible to redirect the location of the generation of .pyc files to other than that of the corresponding .py files? Regards, Swapnil ___ 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
[Python-Dev] A new way to configure logging
At present, configuration of Python's logging package can be done in one of two ways: 1. Create a ConfigParser-readable configuration file and use logging.config.fileConfig() to read and implement the configuration therein. 2. Use the logging API to programmatically configure logging using getLogger(), addHandler() etc. The first of these works for simple cases but does not cover all of the logging API (e.g. Filters). The second of these provides maximal control, but besides requiring users to write the configuration code, it fixes the configuration in Python code and does not facilitate changing it easily at runtime. In addition, the ConfigParser format appears to engender dislike (sometimes strong dislike) in some quarters. Though it was chosen because it was the only configuration format supported in the stdlib at that time, many people regard it (or perhaps just the particular schema chosen for logging's configuration) as 'crufty' or 'ugly', in some cases apparently on purely aesthetic grounds. Recent versions of Python of course support an additional battery-included format which can be used for configuration - namely, JSON. Other options, such as YAML, are also possible ways of configuring systems, Google App Engine-style, and PyYAML has matured nicely. There has also been talk on the django-dev mailing list about providing better support for using Python logging in Django. When it happens (as of course I hope it does) this has the consequence that many new users who use Django but are relatively inexperienced in Python (e.g. in PHP shops which are moving to Django) will become exposed to Python logging. As Django is configured using a Python module and use of ConfigParser-style files is not a common approach in that ecosystem, users will find either of the two approaches outlined above a particular pain point when configuring logging for their Django applications and websites, unless something is done to avoid it. All three of the contenders for the title of "commonly found configuration mechanism" - JSON, YAML and Python code - will be expressible, in Python, as Python dicts. So it seems to make sense to add, to logging.config, a new callable bound to "dictConfig" which will take a single dictionary argument and configure logging from that dictionary. An important facet of implementing such a scheme will be the format or schema which the dictionary has to adhere to. I have started working on what such a schema would look like, and if people here think it's a good idea to go ahead with this, I'll provide the details of the schema on a separate post which I'll also cross-post on comp.lang.python so that I can get feedback from there, too. In outline, the scheme I have in mind will look like this, in terms of the new public API: class DictConfigurator: def __init__(self, config): #config is a dict-like object (duck-typed) import copy self.config = copy.deepcopy(config) def configure(self): # actually do the configuration here using self.config dictConfigClass = DictConfigurator def dictConfig(config): dictConfigClass(config).configure() This allows easy replacement of DictConfigurator with a suitable subclass where needed. What's the general feeling here about this proposal? All comments and suggestions will be gratefully received. 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 byte-compiled and optimized code
On Wed, Oct 7, 2009 at 10:34 AM, Swapnil Talekar wrote: > 1) Is the byte-compiled .pyc file and optimized .pyo file > platform-independent?(including python versions 3.x) Yes. > If yes, is it > guaranteed to stay that way in future? Yes. > 2) If the the generation of .pyc file fails (say, due to write protected > area), does that stop the script execution? No. It only means the bytecode won't be cached. > 3) Is it possible to redirect the location of the generation of .pyc files > to other than that of the corresponding .py files? I think some support for this has been developed, at least experimentally, but I'm not sure if it's part of a stable release or not. It's more likely in Python 3.x, which I'm significantly less familiar with. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] A new way to configure logging
On Wed, Oct 7, 2009 at 9:49 AM, Vinay Sajip wrote:
> At present, configuration of Python's logging package can be done in one of
> two
> ways:
>
> 1. Create a ConfigParser-readable configuration file and use
> logging.config.fileConfig() to read and implement the configuration therein.
> 2. Use the logging API to programmatically configure logging using
> getLogger(),
> addHandler() etc.
>
[...]
Wow ! Great explanation !
;o)
>
> All three of the contenders for the title of "commonly found configuration
> mechanism" - JSON, YAML and Python code - will be expressible, in Python, as
> Python dicts.
.INI files too
{
'section1' :
{'opt11' : 'val1', 'opt12' : 32323},
'section1' :
{'opt21' : 'val2', 'opt22' : 32323},
'section1' :
{'opt31' : 'val3', 'opt32' : 32323},
...
}
In fact it seems that this is a typical characteristic of config formats (CMIIW)
> So it seems to make sense to add, to logging.config, a new
> callable bound to "dictConfig" which will take a single dictionary argument
> and
> configure logging from that dictionary.
>
This kind of problems is similar to the one mentioned in another
thread about modifying config options after executing commands. In
that case I mentioned that the same dict-like interface also holds for
WinReg and so on ...
So thinking big (yes ! I have a big head ! ) I think that the best
approach in this case is to build an adaptation (simple) layer on top
of ConfigParser, JSON, WinReg, PyCode, YAML, ... and build specific
extensions for these formats . Perhaps the proper interfaces are
already there (e.g. `dict`, `shelve` ) and I'm just blind and looking
somewhere else ;o)
If `dict` (possibly nested ;o) is enough to represent config files
then the new method should be ok ... IMHO
[...]
>
> In outline, the scheme I have in mind will look like this, in terms of the new
> public API:
>
> class DictConfigurator:
> def __init__(self, config): #config is a dict-like object (duck-typed)
> import copy
> self.config = copy.deepcopy(config)
Why ?
>
> def configure(self):
> # actually do the configuration here using self.config
>
> dictConfigClass = DictConfigurator
>
> def dictConfig(config):
> dictConfigClass(config).configure()
>
> This allows easy replacement of DictConfigurator with a suitable subclass
> where
> needed.
>
extension is cool ... what's the point about adding the new method
instead of using `DictConfigurator` directly ?
> What's the general feeling here about this proposal?
>
I'm feeling things ... :)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Nabble - Trac Users - Coupling trac and symfony framework -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html
___
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 byte-compiled and optimized code
Fred Drake gmail.com> writes: > > 3) Is it possible to redirect the location of the generation of .pyc files > > to other than that of the corresponding .py files? > > I think some support for this has been developed, at least > experimentally, but I'm not sure if it's part of a stable release or > not. It's more likely in Python 3.x, which I'm significantly less > familiar with. I haven't seen any such thing. If you need pyc files to reside in read-only directories, the best solution would be to generate them at install time (when you have write access to the directories). 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] A new way to configure logging
Olemis Lang gmail.com> writes: > This kind of problems is similar to the one mentioned in another > thread about modifying config options after executing commands. In > that case I mentioned that the same dict-like interface also holds for > WinReg and so on ... > > So thinking big (yes ! I have a big head ! ) I think that the best > approach in this case is to build an adaptation (simple) layer on top > of ConfigParser, JSON, WinReg, PyCode, YAML, ... and build specific > extensions for these formats . Perhaps the proper interfaces are > already there (e.g. `dict`, `shelve` ) and I'm just blind and looking > somewhere else ;o) Sorry, you've lost me :-) > > import copy > > self.config = copy.deepcopy(config) > > Why ? So I'm free to mutate self.config as I see fit. > extension is cool ... what's the point about adding the new method > instead of using `DictConfigurator` directly ? When you say "the new method", if you mean "configure" - the pattern is so that a subclass can override __init__ and do additional setup before configure() is called. 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] Package install failures in 2.6.3
> If setuptools can be made to work with Python 2.6.3 /and/ earlier > versions of Python 2.6.x, then it should be patched and an update > released. If not, then perhaps we should revert the change in a quick > Python 2.6.4. If there is going to be any quick 2.6.4 release, can you consider a fix to the building of extensions under Windows ( http://bugs.python.org/issue4120 )? Extensions built without this patch applied will not work if the MSVC9 runtimes are installed locally (in the Python folder) instead of system-wide (WinSxS). PIL and Matplotlib now use this patch when building extensions. But many others (e.g. PyGame) still create problematic extensions. -Koen ___ 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] A new way to configure logging
Vinay Sajip writes: > What's the general feeling here about this proposal? All comments and > suggestions will be gratefully received. > How about the global logging configuration being available as an object supporting the usual dictionary interface? So you could, for example, do something like: "logging.dictconfig.update(partialconfig)" ___ 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] A new way to configure logging
On Wed, Oct 7, 2009 at 10:49 AM, Vinay Sajip wrote: > Olemis Lang gmail.com> writes: > >> This kind of problems is similar to the one mentioned in another >> thread about modifying config options after executing commands. In >> that case I mentioned that the same dict-like interface also holds for >> WinReg and so on ... >> >> So thinking big (yes ! I have a big head ! ) I think that the best >> approach in this case is to build an adaptation (simple) layer on top >> of ConfigParser, JSON, WinReg, PyCode, YAML, ... and build specific >> extensions for these formats . Perhaps the proper interfaces are >> already there (e.g. `dict`, `shelve` ) and I'm just blind and looking >> somewhere else ;o) > > Sorry, you've lost me :-) > Never mind . I was just trying to say that using `dict`, an adapter could be implemented (if not already there ;o) for multiple formats like the ones I mentioned above and the solution would cover many config formats ... and also I was saying that I was not sure about whether this is correct , I mean for *ANY* config formats, but definitely will work for many ;o) >> > import copy >> > self.config = copy.deepcopy(config) >> >> Why ? > > So I'm free to mutate self.config as I see fit. > why not to let the user do it if he | she thinks so. I mean if somebody supplies in a temporary mapping that can be written then why to spend that time cloning the dict ? If the function has side-effects, well just document it ;o) >> extension is cool ... what's the point about adding the new method >> instead of using `DictConfigurator` directly ? > > When you say "the new method", if you mean "configure" - the pattern is so > that > a subclass can override __init__ and do additional setup before configure() is > called. > Sorry I was confused. I was talking about `dictConfig` *FUNCTION* (to be added to logging.config ... isn't it ? ;o). I mean if dictConfig is sematically equivalent to a simple `dc.configure` why to add such function ? PS: Not a big problem anyway ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Looking for a technique to create flexible, graphical dashboards ... - http://feedproxy.google.com/~r/TracGViz-full/~3/71kRhT34BgU/43789 ___ 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] A new way to configure logging
On Wed, Oct 7, 2009 at 11:06 AM, Paul Rudin wrote: > Vinay Sajip writes: > > >> What's the general feeling here about this proposal? All comments and >> suggestions will be gratefully received. >> > > How about the global logging configuration being available as an object > supporting the usual dictionary interface? So you could, for example, do > something like: "logging.dictconfig.update(partialconfig)" > Seems interesting ... yes ! ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Search for milestone change in change history - Trac Users ... - http://feedproxy.google.com/~r/TracGViz-full/~3/Gsj4xLjuCtk/578d40b734e5e753 ___ 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] a new setuptools release?
+1 For a large number of people [1, 2, 3], setuptools is already a critical part of Python. Make it official. Let everyone know that future releases of Python will not break setuptools/Distribute, and that they can rely on backwards-compatibility with the myriad existing packages. Make the next release of the distutils standard lib module be Distribute. (Perhaps some people will complain, but they can channel their energy into improving the new distutils.) Regards, Zooko [1] The majority of professional developers using Python rely on setuptools to distribute and to use packages: http://tarekziade.wordpress.com/2009/03/26/packaging-survey-first-results/ [2] setuptools is one of the most downloaded packages on PyPI: http://pypi.python.org/pypi/setuptools http://blog.delaguardia.com.mx/tags/pypi [3] about one fifth of Debian users who install python2.5 also install python-pkg-resources: http://qa.debian.org/popcon.php?package=python-setuptools http://qa.debian.org/popcon.php?package=python2.5 ___ 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
[Python-Dev] please consider changing --enable-unicode default to ucs4
Folks: I accidentally sent this letter just to MAL when I intended it to python-dev. Please read it, as it explains why the issue I'm raising is not just the "we should switch to ucs4 because it is better" issue that was previously settled by GvR. This is a current, practical problem that is preventing people from distributing and using Python packages with binary extension modules on Linux. Regards, Zooko -- Forwarded message -- From: Zooko O'Whielacronx Date: Sun, Sep 27, 2009 at 11:43 AM Subject: Re: [Python-Dev] please consider changing --enable-unicode default to ucs4 To: "M.-A. Lemburg" Folks: I'm sorry, I think I didn't make my concern clear. My users, and lots of other users, are having a problem with incompatibility between Python binary extension modules. One way to improve the situation would be if the Python devs would use their "bully pulpit" -- their unique position as a source respected by all Linux distributions -- and say "We recommend that Linux distributions use UCS4 for compatibility with one another". This would not abrogate anyone's ability to choose their preferred setting nor, as far as I can tell, would it interfere with the ongoing development of Python. Here are the details: I'm the maintainer of several Python packages. I work hard to make it easy for users, even users who don't know anything about Python, to use my software. There have been many pain points in this process and I've spent a lot of time on it for about three years now working on packaging, including the tools such as setuptools and distutils and the new "distribute" tool. Python packaging has been improving during these years -- things are looking up. One of the remaining pain points is that I can distribute binaries of my Python extension modules for Windows or Mac, but if I distribute a binary Python extension module on Linux, then if the user has a different UCS2/UCS4 setting then they won't be able to use the extension module. The current de facto standard for Linux is UCS4 -- it is used by Debian, Ubuntu, Fedora, RHEL, OpenSuSE, etc. etc.. The vast majority of Linux users in practice have UCS4, and most binary Python modules are compiled for UCS4. That means that a few folks will get left out. Those folks, from my experience, are people who built their python executable themselves without specifying an override for the default, and the smaller Linux distributions who insist on doing whatever upstream Python devs recommend instead of doing whatever the other Linux distros are doing. One of the data points that I reported was a Python interpreter that was built locally on an Ubuntu server. Since the person building it didn't know to override the default setting of --enable-unicode, he ended up with a Python interpreter built for UCS2, even though all the Python extension modules shipped by Ubuntu were built with UCS4. These are not isolated incidents. The following google searches suggest that a number of people spend time trying to figure out why Python extension modules fail on their linux systems: http://www.google.com/search?q=PyUnicodeUCS4_FromUnicode+undefined+symbol http://www.google.com/search?q=+PyUnicodeUCS2_FromUnicode+undefined+symbol http://www.google.com/search?q=_PyUnicodeUCS2_AsDefaultEncodedString+undefined+symbol Another data point is the Mandriva Linux distribution. It is probably much smaller than Debian, Ubuntu, or RedHat, but it is still one of the major, well-known distributions. I requested of the Python maintainer for Mandriva, Michael Scherer, that they switch from UCS2 to UCS4 in order to reduce compatibility problems like these. His answer as I understood it was that it is best to follow the recommendations of the upstream Python devs by using the default setting instead of choosing a setting for himself. (Now we could implement a protocol which would show whether a given Python package was compiled for UCS2 or UCS4. That would be good. Hopefully it would make incompatibility more explicit and understandable to users. Here is a ticket for that -- which project I am contributing to: http://bugs.python.org/setuptools/issue78 . However, even if we implement that feature in the distribute tool (the successor to setuptools), users who build their own python or who use a Linux distribution that follows upstream configuration defaults will still be unable to use most Python packages with compiled extension modules.) In a message on this thread, MvL wrote: > "For that reason I think it's also better that the configure script > continues to default to UTF-16 -- this will give the UTF-16 support > code the necessary exercise." > > This is effectively a BDFL pronouncement. Nothing has changed the > validity of the premise of the statement, so the conclusion remains > valid, as well. My understand of the earlier thread was that someone suggested that UCS4 would be technically better and GvR decided that there were technical reasons to cont
Re: [Python-Dev] Python byte-compiled and optimized code
Fred Drake wrote: On Wed, Oct 7, 2009 at 10:34 AM, Swapnil Talekar wrote: 1) Is the byte-compiled .pyc file and optimized .pyo file platform-independent?(including python versions 3.x) Yes. To be clear, CPython's .pyc is platform independent for a particular x.y version, and should, I believe, stay the same for all x.y.z releases, but the format of .pyc may change slightly from x.y to x.(y+1) ___ 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] A new way to configure logging
Paul Rudin writes:
> How about the global logging configuration being available as an object
> supporting the usual dictionary interface? So you could, for example, do
> something like: "logging.dictconfig.update(partialconfig)"
A "partial configuration" only makes sense under certain limited conditions. For
example, a dict used for configuration will map to a graph of objects - filters,
formatters, handlers and loggers - which by necessity need to be referred to via
a string key in the dict - because you can't easily encode a graph in a dict
which comes from, say, a YAML or JSON file. These keys are temporary and just
used to indicate e.g. which handlers to attach to which loggers for that
particular configuration call:
{
"handlers": {
"h1": {
configuration for a handler
},
"h2": {
configuration for another handler
},
"h3": {
configuration for yet another handler
},
},
"loggers": {
"foo": {
"level": "DEBUG",
"handlers": ["h1", "h3"],
},
"bar.baz": {
"level": "INFO",
"handlers": ["h2", "h3"],
},
"spam.eggs": {
"level": "ERROR",
"handlers": ["h1", "h3"],
},
}
}
Here, the keys "h1", "h2" etc. are just used to encode connections in the graph,
and are useless outside the context of the specific configuration call. If you
pass a partial configuration, to be implemented incrementally, there's no way of
knowing if (in general) it's going to be consistent with the existing
configuration. Nor can you refer to e.g. handlers, formatters or filters you
passed in earlier configuration calls.
Since logger names such as "foo", "bar.baz" in the above example *are*
meaningful across multiple configuration calls, it *would be* possible to make
certain changes in the configuration - such as changing levels of loggers - by
passing in a partial configuration. However, if this "partial" functionality is
provided without restriction, it's hard to ensure that a user doesn't
inadvertently misconfigure logging. And while that is equally true with a
one-shot configuration, it's at least easier to debug. Things can get pretty
murky from a diagnostic point of view if code can make arbitrary changes to the
logging configuration during application execution, so that's not a good
practice to encourage :-)
Also, providing a readable dict-like interface to the internal configuration
will almost certainly lead to backward-compatibility headaches in the future.
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] a new setuptools release?
On Wed, Oct 07, 2009 at 10:56:49AM -0600, Zooko O'Whielacronx wrote: > For a large number of people [1, 2, 3], setuptools is already a > critical part of Python. Make it official. Let everyone know that > future releases of Python will not break setuptools/Distribute, and > that they can rely on backwards-compatibility Who will pay the price of maintaining that part of stdlib and the price of compatibility? Because there is always a price; should the core developers be burdened? Oleg. -- Oleg Broytmanhttp://phd.pp.ru/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ 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
[Python-Dev] Python 2.6.4rc1
Hello everyone. The source tarballs and Windows installers for Python 2.6.4rc1 are now available: http://www.python.org/download/releases/2.6.4/ Please download them, install them, and try to use them with your projects and environments. Let us know if you encounter any problems with them. Hopefully we can avoid the situation with 2.6.3 having such critical bugs. 2.6.4 final is planned for 18-October. Cheers, -Barry PGP.sig Description: This is a digitally signed message part ___ 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] a new setuptools release?
P.J. Eby wrote:
> At 01:14 PM 10/6/2009 -0700, Guido van Rossum wrote:
>> suggest nobody hold their breath waiting for setuptools 0.7.
>
> I've never suggested or implied otherwise.
>
> But, if you like Distribute so much, why not just add it directly to the
> stdlib? ;-)
>
> There are many wins to be had from such a move, not the least of which
> is that it allows something to go into the stdlib that isn't
> (branding-wise) associated with me or setuptools, and lets it become
> owned/supported by an even wider community.
I think the biggest problem here is that the brand ("setuptools") is so
ingrained in the world that someone releasing something
setuptools-but-not-setuptools ("Distribute") is at a serious
disadvantage. Your insistence on retaining the name "setuptools" for
yourself and your vapor-ware only harms the community at-large.
Even experienced developers are unaware of Distribute's existence.. I
was entirely unaware until yourself and PJE got in a bickering exchange
on Python-Dev this past month. The extremely high visibility of your
stale package compared to their non-stale package is quite unfortunate.
You are free to say, "that is their problem," but you are not free to
say, "it is not my fault."
> AFAIK, the only reason they've had multiple releases of it is to
> address the issues with its hijacking of setuptools; in a stdlib
> version all that stuff could be dropped. Otherwise, it'd already be
> "mature".
IOW, you acknowledge that your own position and requiring them to
tolerate the parallel existence (in the world) of setuptools harms
Distribute. I fail to see how this relates to being in the stdlib. As
long as it is not called "setuptools" and packages in the world say
"import setuptools", then there are conflicts they will be forced to
managed. And moreover, as long as a stale, perhaps buggy version of
setuptools is the compatibility model they must emulate, they will have
a hard time coexisting.
> Less political bickering, and the some of the technical results I
> hoped for all along are achieved. Yay, open source.
And yet, political bickering seems to be all you are good for in this case.
--
Scott Dial
[email protected]
[email protected]
___
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] transitioning from % to {} formatting
Vinay Sajip yahoo.co.uk> writes:
>
> >>> "%0#8x" % 0x1234
> '0x001234'
> >>> "{0:0>#8x}".format(0x1234)
> '000x1234'
Apart from the sheer unreadability of the {}-style format string, the result
looks rather unexpected from a human being's point of view.
(in those situations, I would output the 0x manually anyway, such as:
>>> "0x%06x" % 0x1234
'0x001234'
>>> "0x{:06x}".format(0x1234)
'0x001234'
)
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] Python 2.6.4rc1
Barry Warsaw wrote: > 2.6.4 final is planned for 18-October. Barry, I suspect this release is primarily to quench the problems with distutils, but.. http://bugs.python.org/issue5949 doesn't seem to have been addressed by you. And this seems like it would be another unfortunate loss of an opportunity. -- Scott Dial [email protected] [email protected] ___ 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] a new setuptools release?
Zooko O'Whielacronx wrote: > +1 > > For a large number of people [1, 2, 3], setuptools is already a > critical part of Python. Make it official. Let everyone know that > future releases of Python will not break setuptools/Distribute, and > that they can rely on backwards-compatibility with the myriad existing > packages. Make the next release of the distutils standard lib module > be Distribute. > > (Perhaps some people will complain, but they can channel their energy > into improving the new distutils.) We've had that discussion in past and a few times. setuptools/Distribute is not distutils, just an add-on (and there are others as well). There are good concepts in setuptools, but the implementation is just not suitable for stdlib integration. Hopefully, Distribute can fix the hacks, trim down the number of features to what people really use, add a proper uninstall command and then we can have the add-to-the-stdlib discussion again. Having more competition will also help, e.g. ActiveState's PyPM looks promising (provided they choose to open-source it) and then there's pip. Things look promising, indeed. > Regards, > > Zooko > > [1] The majority of professional developers using Python rely on > setuptools to distribute and to use packages: > > http://tarekziade.wordpress.com/2009/03/26/packaging-survey-first-results/ > [2] setuptools is one of the most downloaded packages on PyPI: > http://pypi.python.org/pypi/setuptools > http://blog.delaguardia.com.mx/tags/pypi > [3] about one fifth of Debian users who install python2.5 also install > python-pkg-resources: > http://qa.debian.org/popcon.php?package=python-setuptools > http://qa.debian.org/popcon.php?package=python2.5 > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/mal%40egenix.com -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 07 2009) >>> 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 [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] transitioning from % to {} formatting
Antoine Pitrou pitrou.net> writes:
>
> Vinay Sajip yahoo.co.uk> writes:
> >
> > >>> "%0#8x" % 0x1234
> > '0x001234'
> > >>> "{0:0>#8x}".format(0x1234)
> > '000x1234'
>
> Apart from the sheer unreadability of the {}-style format string, the result
> looks rather unexpected from a human being's point of view.
>
> (in those situations, I would output the 0x manually anyway, such as:
> >>> "0x%06x" % 0x1234
> '0x001234'
> >>> "0x{:06x}".format(0x1234)
> '0x001234'
> )
>
Well of course, but I asked the question in the context of providing an
*automatic* converter from %-format strings to {}-format. At the moment, it
doesn't seem like a 100%-faithful automatic conversion is feasible.
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] a new setuptools release?
On Wed, Oct 7, 2009 at 7:27 PM, M.-A. Lemburg wrote: > Zooko O'Whielacronx wrote: >> +1 >> >> For a large number of people [1, 2, 3], setuptools is already a >> critical part of Python. Make it official. Let everyone know that >> future releases of Python will not break setuptools/Distribute, and >> that they can rely on backwards-compatibility with the myriad existing >> packages. Make the next release of the distutils standard lib module >> be Distribute. >> >> (Perhaps some people will complain, but they can channel their energy >> into improving the new distutils.) > > We've had that discussion in past and a few times. setuptools/Distribute > is not distutils, just an add-on (and there are others as well). > > There are good concepts in setuptools, but the implementation is just > not suitable for stdlib integration. > > Hopefully, Distribute can fix the hacks, trim down the number of > features to what people really use, add a proper uninstall command and > then we can have the add-to-the-stdlib discussion again. > > Having more competition will also help, e.g. ActiveState's PyPM looks > promising (provided they choose to open-source it) and then there's > pip. > > Things look promising, indeed. > 100% Agreed ! And before considering adding "bits" of Distribute (or Setuptools) in Distutils, we need to finish our work on PEP 376 and PEP 386, and the changes we've planned for PEP 341. The work we've done there so far in these PEPs is basically trying to have a consensus on the missing standard that is lacking in Distutils, and that was partially solved by Setuptools. I have good hopes that these PEP will be finished before 2.7 is out. Notice that PEP 382 (namespaced packages) is already a great step forward. (by the way, I thought this one was accepted, shouldn't its status updated ?) Tarek -- Tarek Ziadé | http://ziade.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] a new setuptools release?
Thanks for the reply, MAL. How would we judge whether Distribute is ready for inclusion in the Python standard lib? Maybe if it has a few more releases, leaving a trail of "closed: fixed" issue tickets behind it? Regards, Zooko ___ 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 byte-compiled and optimized code
You might be interested in the new PYTHONDONTWRITEBYTECODE environment variable supported as of Python 2.6. I personally think it is a great improvement. :-) Regards, Zooko ___ 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] Package install failures in 2.6.3
On Oct 7, 2009, at 10:54 AM, Koen van de Sande wrote: If there is going to be any quick 2.6.4 release, can you consider a fix to the building of extensions under Windows ( http://bugs.python.org/issue4120 )? Extensions built without this patch applied will not work if the MSVC9 runtimes are installed locally (in the Python folder) instead of system-wide (WinSxS). PIL and Matplotlib now use this patch when building extensions. But many others (e.g. PyGame) still create problematic extensions. I'm not in favor of including this in 2.6.4 since this wasn't a regression in 2.6.3. However if Martin von Loewis approves of the patch and feels strongly that it should go in 2.6.4, I'll allow it. -Barry PGP.sig Description: This is a digitally signed message part ___ 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] please consider changing --enable-unicode default to ucs4
Zooko O'Whielacronx wrote: > Dear MAL and python-dev: > > I failed to explain the problem that users are having. I will try > again, and this time I will omit my ideas about how to improve things > and just focus on describing the problem. > > Some users are having trouble using Python packages containing binary > extensions on Linux. I want to provide such binary Python packages > for Linux for the pycryptopp project > (http://allmydata.org/trac/pycryptopp ) and the zfec project > (http://allmydata.org/trac/zfec ). I also want to make it possible > for users to install the Tahoe-LAFS project (http://allmydata.org ) > without having a compiler or Python header files. (You'd be surprised > at how often Tahoe-LAFS users try to do this on Linux. Linux is no > longer only for people who have the knowledge and patience to compile > software themselves.) Tahoe-LAFS also depends on many packages that > are maintained by other people and are not packaged or distributed by > me -- pyOpenSSL, simplejson, etc.. > > There have been several hurdles in the way that we've overcome, and no > doubt there will be more, but the current hurdle is that there are two > "formats" for Python extension modules that are used on Linux -- UCS2 > and UCS4. If a user gets a Python package containing a compiled > extension module which was built for the wrong UCS2/4 setting, he will > get mysterious (to him) "undefined symbol" errors at import time. Zooko, I really fail to see the reasoning here: Why would people who know how to build their own Python interpreter on Linux and expect it to work like the distribution-provided one, have a problem looking up the distribution-used configuration settings ? This is like compiling your own Linux kernel without using the same configuration as the distribution kernel and still expecting the distribution kernel modules to load without problems. Note that this has nothing to do with compiling your own Python extensions. Python's distutils will automatically use the right settings for compiling those, based on the configuration of the Python interpreter used for running the compilation - which will usually be the distribution interpreter. Your argument doesn't really live up to the consequences of switching to UCS4. Just as data-point: eGenix has been shipping binaries for Python packages for several years and while we do occasionally get reports about UCS2/UCS4 mismatches, those are really in the minority. I'd also question using the UCS4 default only on Linux. If we do go for a change, we should use sizeof(wchar_t) as basis for the new default - on all platforms that provide a wchar_t type. However, before we can make such a decision, we need more data about the consequences. That is: * memory footprint changes * performance changes For both Python 2.x and 3.x. After all, UCS4 uses twice as much memory for all Unicode objects as UCS2. Since Python 3.x uses Unicode for all strings, I'd expect such a change to have more impact there. We'd also need to look into possible problems with different compilers using different wchar_t sizes on the same platform (I doubt that there are any). On Windows, the default is fixed since Windows uses UTF-16 for everything Unicode, so UCS2 will for a long time be the only option on that platform. That said, it'll take a while for distributions to upgrade, so you're always better off getting the tools you're using to deal with the problem for you and your users, since those are easier to upgrade. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 07 2009) >>> 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 [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 2.6.4rc1
On Oct 7, 2009, at 1:26 PM, Scott Dial wrote: I suspect this release is primarily to quench the problems with distutils, but.. http://bugs.python.org/issue5949 doesn't seem to have been addressed by you. And this seems like it would be another unfortunate loss of an opportunity. I want us to be very careful about 2.6.4. This isn't a normal bug fix release, it's specifically there to remove the brown paper bag of 2.6.3 from our heads. So let's be conservative and fix this one in 2.6.5. -Barry PGP.sig Description: This is a digitally signed message part ___ 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] a new setuptools release?
Zooko O'Whielacronx wrote: > Thanks for the reply, MAL. > > How would we judge whether Distribute is ready for inclusion in the > Python standard lib? Maybe if it has a few more releases, leaving a > trail of "closed: fixed" issue tickets behind it? I guess it'll just have to take the usual path of new modules/packages for the stdlib... http://www.python.org/dev/peps/pep-0002/ (the PEP is a bit outdated, but it still provides a good basis for the process) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 07 2009) >>> 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 [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] transitioning from % to {} formatting
Antoine Pitrou wrote:
Vinay Sajip yahoo.co.uk> writes:
"%0#8x" % 0x1234
'0x001234'
"{0:0>#8x}".format(0x1234)
'000x1234'
Apart from the sheer unreadability of the {}-style format string, the result
looks rather unexpected from a human being's point of view.
(in those situations, I would output the 0x manually anyway, such as:
"0x%06x" % 0x1234
'0x001234'
"0x{:06x}".format(0x1234)
'0x001234'
)
"#" formatting was added to int.__format__ in order to support this case:
>>> format(10, '#6x')
' 0xa'
Without '#', there's no way to specify a field width but still have the
'0x' up against the digits (at least not without generating an
intermediate result and figuring out the width manually).
The fact that it works in combination with '0' or '>' (not sure which
one makes it unreadable to you) wasn't really the point of the feature.
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] please consider changing --enable-unicode default to ucs4
Zooko O'Whielacronx gmail.com> writes: > > I accidentally sent this letter just to MAL when I intended it to > python-dev. Please read it, as it explains why the issue I'm raising > is not just the "we should switch to ucs4 because it is better" issue > that was previously settled by GvR. For what it's worth, with stringbench under py3k, an UCS2 build is roughly 8% faster than an UCS4 build (190 s. total against 206 s.). ___ 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] a new setuptools release?
I'm not really sure how to reply to your email, since it seems to be
based on several major misunderstandings. So, just a few key points:
* Distribute 0.6.x is a stable maintenance branch, much like setuptools 0.6
* Distribute 0.7 is vaporware, very much like setuptools 0.7
* Packages using distribute 0.6.x still say "import setuptools"
* Suggesting that the stdlib include the *other guys' code* is not
"political bickering" - it's a positive proposal for moving forward
that eliminates both technical and political obstacles. If you
thought I was being sarcastic or ironic, you are mistaken.
At 01:22 PM 10/7/2009 -0400, Scott Dial wrote:
P.J. Eby wrote:
> At 01:14 PM 10/6/2009 -0700, Guido van Rossum wrote:
>> suggest nobody hold their breath waiting for setuptools 0.7.
>
> I've never suggested or implied otherwise.
>
> But, if you like Distribute so much, why not just add it directly to the
> stdlib? ;-)
>
> There are many wins to be had from such a move, not the least of which
> is that it allows something to go into the stdlib that isn't
> (branding-wise) associated with me or setuptools, and lets it become
> owned/supported by an even wider community.
I think the biggest problem here is that the brand ("setuptools") is so
ingrained in the world that someone releasing something
setuptools-but-not-setuptools ("Distribute") is at a serious
disadvantage. Your insistence on retaining the name "setuptools" for
yourself and your vapor-ware only harms the community at-large.
Even experienced developers are unaware of Distribute's existence.. I
was entirely unaware until yourself and PJE got in a bickering exchange
on Python-Dev this past month. The extremely high visibility of your
stale package compared to their non-stale package is quite unfortunate.
You are free to say, "that is their problem," but you are not free to
say, "it is not my fault."
> AFAIK, the only reason they've had multiple releases of it is to
> address the issues with its hijacking of setuptools; in a stdlib
> version all that stuff could be dropped. Otherwise, it'd already be
> "mature".
IOW, you acknowledge that your own position and requiring them to
tolerate the parallel existence (in the world) of setuptools harms
Distribute. I fail to see how this relates to being in the stdlib. As
long as it is not called "setuptools" and packages in the world say
"import setuptools", then there are conflicts they will be forced to
managed. And moreover, as long as a stale, perhaps buggy version of
setuptools is the compatibility model they must emulate, they will have
a hard time coexisting.
> Less political bickering, and the some of the technical results I
> hoped for all along are achieved. Yay, open source.
And yet, political bickering seems to be all you are good for in this case.
--
Scott Dial
[email protected]
[email protected]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com
___
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] please consider changing --enable-unicode default to ucs4
On 7 Oct, 2009, at 20:05, M.-A. Lemburg wrote: If we do go for a change, we should use sizeof(wchar_t) as basis for the new default - on all platforms that provide a wchar_t type. I'd be -1 on that. Sizeof(wchar_t) is 4 on OSX, but all non-Unix API's that deal with Unicode text use ucs16. Ronald smime.p7s Description: S/MIME cryptographic 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] a new setuptools release?
At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote: Having more competition will also help, e.g. ActiveState's PyPM looks promising (provided they choose to open-source it) and then there's pip. Note that both PyPM and pip use setuptools as an important piece of their implementation (as does buildout), so they are technically the competition of easy_install, rather than setuptools per se. IOW, putting setuptools in the stdlib wouldn't be declaring a victor in the installation tools competition, it'd simply be providing infrastructure for (present and future) tools to build on. ___ 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] a new setuptools release?
P.J. Eby wrote: At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote: Having more competition will also help, e.g. ActiveState's PyPM looks promising (provided they choose to open-source it) and then there's pip. Note that both PyPM and pip use setuptools as an important piece of their implementation (as does buildout), so they are technically the competition of easy_install, rather than setuptools per se. IOW, putting setuptools in the stdlib wouldn't be declaring a victor in the installation tools competition, it'd simply be providing infrastructure for (present and future) tools to build on. I'd like to see PEP 370 (user site-packages folders) compatibility as a pre-condition of moving Distribute (or components of it) into the standard library. There are some issues around PEP 370 for alternative implementations that I'd like to address as a compatibility fix for Python 2.6 as well. :-) Michael ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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 2.6.4rc1
On 7 Oct, 2009, at 20:53, Brett Cannon wrote:I just tried building out of svn and a ton of tests that rely on urllib failed because the _scproxy module wasn't built and it unconditionally imports it under darwin. Turns out that it requires the Mac toolbox glue to be built which I always skip since I don't care about it.
I am fairly certain this toolbox glue dependency for urllib is a regression as I used to always be able to get networking working w/o the Mac-specific modules.Bummer. _scproxy was introduced in 2.6.3 to fix a crash in the ctypes based code it replaces, as well as very vague failures in the same code on OSX 10.5 Server on PPC machines.Luckily the fix is easy enough: move some code in setup.py from the block that checks for "not --disable-toolbox-glue", the _scproxy module has no dependencies on the toolbox glue.The attached patch should fix the issue,RonaldIndex: setup.py
===
--- setup.py(revision 75268)
+++ setup.py(working copy)
@@ -1349,6 +1349,15 @@
else:
missing.append('sunaudiodev')
+if platform == 'darwin':
+# _scproxy
+exts.append(Extension("_scproxy", [os.path.join(srcdir,
"Mac/Modules/_scproxy.c")],
+extra_link_args= [
+'-framework', 'SystemConfiguration',
+'-framework', 'CoreFoundation'
+]))
+
+
if platform == 'darwin' and ("--disable-toolbox-glue" not in
sysconfig.get_config_var("CONFIG_ARGS")):
@@ -1402,15 +1411,6 @@
addMacExtension('_CF', core_kwds, ['cf/pycfbridge.c'])
addMacExtension('autoGIL', core_kwds)
-# _scproxy
-sc_kwds = {
-'extra_compile_args': carbon_extra_compile_args,
-'extra_link_args': [
-'-framework', 'SystemConfiguration',
-'-framework', 'CoreFoundation'
-],
-}
-addMacExtension("_scproxy", sc_kwds)
# Carbon
-Brett
On Wed, Oct 7, 2009 at 10:18, Barry Warsaw wrote:
Hello everyone.
The source tarballs and Windows installers for Python 2.6.4rc1 are now available:
http://www.python.org/download/releases/2.6.4/
Please download them, install them, and try to use them with your projects and environments. Let us know if you encounter any problems with them. Hopefully we can avoid the situation with 2.6.3 having such critical bugs.
2.6.4 final is planned for 18-October.
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/brett%40python.org
smime.p7s
Description: S/MIME cryptographic 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] a new setuptools release?
On Wed, Oct 7, 2009 at 10:37, Zooko O'Whielacronx wrote: > Thanks for the reply, MAL. > > How would we judge whether Distribute is ready for inclusion in the > Python standard lib? Maybe if it has a few more releases, leaving a > trail of "closed: fixed" issue tickets behind it? > When Tarek says it's ready. -Brett ___ 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] please consider changing --enable-unicode default to ucs4
Ronald Oussoren wrote: > > On 7 Oct, 2009, at 20:05, M.-A. Lemburg wrote: >> >> >> If we do go for a change, we should use sizeof(wchar_t) >> as basis for the new default - on all platforms that >> provide a wchar_t type. > > I'd be -1 on that. Sizeof(wchar_t) is 4 on OSX, but all non-Unix API's > that deal with Unicode text use ucs16. Is that true for non-Carbon APIs as well ? This is what I found on the web (in summary): Apple chose to go with UTF-16 at about the same time as Microsoft did and used sizeof(wchar_t) == 2 for Mac OS. When they moved to Mac OS X, they switched wchar_t to sizeof(wchar_t) == 4. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 07 2009) >>> 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 [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] eggs now mandatory for pypi?
Arc Riley gmail.com> writes: > > Is the intention of Pypi really to turn it into a social networking site? Sure, why not? It's not like there are enough social networking sites nowadays, are there? :) 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] please consider changing --enable-unicode default to ucs4
On 7 Oct, 2009, at 22:13, M.-A. Lemburg wrote: Ronald Oussoren wrote: On 7 Oct, 2009, at 20:05, M.-A. Lemburg wrote: If we do go for a change, we should use sizeof(wchar_t) as basis for the new default - on all platforms that provide a wchar_t type. I'd be -1 on that. Sizeof(wchar_t) is 4 on OSX, but all non-Unix API's that deal with Unicode text use ucs16. Is that true for non-Carbon APIs as well ? This is what I found on the web (in summary): Apple chose to go with UTF-16 at about the same time as Microsoft did and used sizeof(wchar_t) == 2 for Mac OS. When they moved to Mac OS X, they switched wchar_t to sizeof(wchar_t) == 4. Both Carbon and the modern APIs use UTF-16. What I don't quite get in the UTF-16 vs. UTF-32 discussion is why UTF-32 would be useful, because if you want to do generic Unicode processing you have to look at sequences of composed characters (base characters + composing marks) anyway instead of separate code points. Not that I'm a unicode expert in any way... Ronald smime.p7s Description: S/MIME cryptographic 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] a new setuptools release?
P.J. Eby telecommunity.com> writes: > * Distribute 0.6.x is a stable maintenance branch, much like setuptools 0.6 I'm new to this particular discussion so feel free to correct me if I'm wrong, but ISTM that Distribute 0.6.x differs markedly from setuptools 0.6 in that the former has an active maintainer and the latter does not, or am I wrong about that? 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] a new setuptools release?
On Wed, 07 Oct 2009 12:35:18 -0700, P.J. Eby wrote: At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote: Having more competition will also help, e.g. ActiveState's PyPM looks promising (provided they choose to open-source it) and then there's pip. Note that both PyPM and pip use setuptools as an important piece of their implementation (as does buildout), so they are technically the competition of easy_install, rather than setuptools per se. IOW, putting setuptools in the stdlib wouldn't be declaring a victor in the installation tools competition, it'd simply be providing infrastructure for (present and future) tools to build on. PyPM client relies on pkg_resources *only*[1]. Specifically for 1) the version comparison algorithm: $ grep pkg_resources pypm/client/version.py import pkg_resources return cmp(pkg_resources.parse_version(pkg1.version), pkg_resources.parse_version(pkg2.version)) 2) parsing the "install_requires" string: $ grep parse pypm/client/dependency.py return [pkg_resources.Requirement.parse(reqstring) Both these features are definitely worthy of addition to stdlib but only after *standardizing* them (like PEP 376 does with .egg-info structure and files list). Now that Distribute is getting some visibility, it will be extremely good for the community to add distribute-0.7 (which would include the above two features apart from others) to the stdlib. -srid *** [1] The backend code (our mirroring component) also uses setuptools.package_index ___ 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] a new setuptools release?
P.J. Eby wrote: > At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote: >> Having more competition will also help, e.g. ActiveState's PyPM looks >> promising (provided they choose to open-source it) and then there's >> pip. > > Note that both PyPM and pip use setuptools as an important piece of > their implementation (as does buildout), so they are technically the > competition of easy_install, rather than setuptools per se. > > IOW, putting setuptools in the stdlib wouldn't be declaring a victor in > the installation tools competition, it'd simply be providing > infrastructure for (present and future) tools to build on. I'm sure that some implementation of some of the concepts of setuptools will end up in the stdlib - in a well-integrated and distutils compatible form. Perhaps we can even find a way to remove the need for .pth files and long sys.path lists :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 07 2009) >>> 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 [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 2.6.4rc1
On Wed, Oct 7, 2009 at 12:42, Ronald Oussoren wrote: > > On 7 Oct, 2009, at 20:53, Brett Cannon wrote: > > I just tried building out of svn and a ton of tests that rely on urllib > failed because the _scproxy module wasn't built and it unconditionally > imports it under darwin. Turns out that it requires the Mac toolbox glue to > be built which I always skip since I don't care about it. > I am fairly certain this toolbox glue dependency for urllib is a regression > as I used to always be able to get networking working w/o the Mac-specific > modules. > > > Bummer. _scproxy was introduced in 2.6.3 to fix a crash in the ctypes based > code it replaces, as well as very vague failures in the same code on OSX > 10.5 Server on PPC machines. > > Luckily the fix is easy enough: move some code in setup.py from the block > that checks for "not --disable-toolbox-glue", the _scproxy module has no > dependencies on the toolbox glue. > > The attached patch should fix the issue, > > Patch fixed it. Barry, can Ronald apply the patch? -Brett > Ronald > > > > > -Brett > > On Wed, Oct 7, 2009 at 10:18, Barry Warsaw wrote: > >> Hello everyone. >> >> The source tarballs and Windows installers for Python 2.6.4rc1 are now >> available: >> >> http://www.python.org/download/releases/2.6.4/ >> >> Please download them, install them, and try to use them with your projects >> and environments. Let us know if you encounter any problems with them. >> Hopefully we can avoid the situation with 2.6.3 having such critical bugs. >> >> 2.6.4 final is planned for 18-October. >> >> 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/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] a new setuptools release?
At 08:23 PM 10/7/2009 +, Vinay Sajip wrote: P.J. Eby writes: > * Distribute 0.6.x is a stable maintenance branch, much like setuptools 0.6 I'm new to this particular discussion so feel free to correct me if I'm wrong, but ISTM that Distribute 0.6.x differs markedly from setuptools 0.6 in that the former has an active maintainer and the latter does not, or am I wrong about that? That depends on how you define "active". I haven't resigned, nor do I plan to. There's simply a long mean time between releases at the moment, and some people feel that it's too long. That's certainly their prerogative, but it doesn't mean I have to agree with such characterizations. ___ 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] a new setuptools release?
On Wed, Oct 7, 2009 at 10:43 PM, Sridhar Ratnakumar wrote: > PyPM client relies on pkg_resources *only*[1]. Specifically for > > 1) the version comparison algorithm: [...] > > 2) parsing the "install_requires" string: > [...] > > Both these features are definitely worthy of addition to stdlib but only > after *standardizing* them (like PEP 376 does with .egg-info structure and > files list). Now that Distribute is getting some visibility, it will be > extremely good for the community to add distribute-0.7 (which would include > the above two features apart from others) to the stdlib. Three remarks : - Distutils contains already a version comparison algorithm, and the version comparison algorithm is being reworked in PEP 386. The goal is to provide a version scheme that allows adding a field like install_requires in PEP 341, and would allow package manager to compare versions. - The roadmap of Distribute includes the splitting you are mentioning - I don't think that adding Distribute-0.7 to the stdlib it the best plan : I'd rather see bits of them included in Distutils, with Distribute being an incubator because its release cycle is shorter. I will push on python-dev a detailed roadmap of Distutils we had in mind and what it means for Python 2.7. Give me a day or so to prepare it. Regards Tarek ___ 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] a new setuptools release?
At 10:46 PM 10/7/2009 +0200, M.-A. Lemburg wrote: P.J. Eby wrote: > At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote: >> Having more competition will also help, e.g. ActiveState's PyPM looks >> promising (provided they choose to open-source it) and then there's >> pip. > > Note that both PyPM and pip use setuptools as an important piece of > their implementation (as does buildout), so they are technically the > competition of easy_install, rather than setuptools per se. > > IOW, putting setuptools in the stdlib wouldn't be declaring a victor in > the installation tools competition, it'd simply be providing > infrastructure for (present and future) tools to build on. I'm sure that some implementation of some of the concepts of setuptools will end up in the stdlib - in a well-integrated and distutils compatible form. Perhaps we can even find a way to remove the need for .pth files and long sys.path lists :-) Setuptools doesn't *require* either of those now. Installing in flat, distutils-compatible format has been supported for years, and .pth files are only needed for good namespace package support. But PEP 382 makes namespace packages possible without .pth files, so even that could go away. ___ 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 2.6.4rc1
On Oct 7, 2009, at 3:46 PM, Brett Cannon wrote: On Wed, Oct 7, 2009 at 12:42, Ronald Oussoren wrote: On 7 Oct, 2009, at 20:53, Brett Cannon wrote: I just tried building out of svn and a ton of tests that rely on urllib failed because the _scproxy module wasn't built and it unconditionally imports it under darwin. Turns out that it requires the Mac toolbox glue to be built which I always skip since I don't care about it. I am fairly certain this toolbox glue dependency for urllib is a regression as I used to always be able to get networking working w/ o the Mac-specific modules. Bummer. _scproxy was introduced in 2.6.3 to fix a crash in the ctypes based code it replaces, as well as very vague failures in the same code on OSX 10.5 Server on PPC machines. Luckily the fix is easy enough: move some code in setup.py from the block that checks for "not --disable-toolbox-glue", the _scproxy module has no dependencies on the toolbox glue. The attached patch should fix the issue, Patch fixed it. Barry, can Ronald apply the patch? Since this is a 2.6.3 regression, yes. Thanks, -Barry PGP.sig Description: This is a digitally signed message part ___ 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] please consider changing --enable-unicode default to ucs4
Ronald Oussoren wrote: > > On 7 Oct, 2009, at 22:13, M.-A. Lemburg wrote: > >> Ronald Oussoren wrote: >>> >>> On 7 Oct, 2009, at 20:05, M.-A. Lemburg wrote: If we do go for a change, we should use sizeof(wchar_t) as basis for the new default - on all platforms that provide a wchar_t type. >>> >>> I'd be -1 on that. Sizeof(wchar_t) is 4 on OSX, but all non-Unix API's >>> that deal with Unicode text use ucs16. >> >> Is that true for non-Carbon APIs as well ? >> >> This is what I found on the web (in summary): >> >> Apple chose to go with UTF-16 at about the same time as Microsoft did >> and used sizeof(wchar_t) == 2 for Mac OS. When they moved to Mac OS X, >> they switched wchar_t to sizeof(wchar_t) == 4. >> > > Both Carbon and the modern APIs use UTF-16. Thanks for that data point. So UTF-16 would be the more natural choice on Mac OS X, despite the choice of sizeof(wchar_t). > What I don't quite get in the UTF-16 vs. UTF-32 discussion is why UTF-32 > would be useful, because if you want to do generic Unicode processing > you have to look at sequences of composed characters (base characters + > composing marks) anyway instead of separate code points. Not that I'm a > unicode expert in any way... Very true. It's one of the reasons why I'm not much of a UCS4-fan - it only helps with surrogates and that's about it. Combining characters, various types of control code points (e.g. joiners, bidirectional marks, breaks, non-breaks, annotations) context sensitive casing, bidirectional marks and other such features found in scripts cause very similar problems - often much harder to solve, since they are not as easily identifiable as surrogate high and low code points. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 07 2009) >>> 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 [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 389: argparse - new command line parsing module
Hrvoje Niksic avl.com> writes: > > Of course; simply use the >&- pseudo-redirection, which has been a > standard sh feature (later inherited by ksh and bash, but not csh) for > ~30 years. The error message is amusing, too: > > $ python -c 'print "foo"' >&- > close failed in file object destructor: > Error in sys.excepthook: > > Original exception was: Python 3 complains at startup and is a bit more explicit: $ ./python -c '1' >&- Fatal Python error: Py_Initialize: can't initialize sys standard streams OSError: [Errno 9] Bad file descriptor Abandon Of course, if it is stderr that you explicitly close, you lose all reporting: $ ./python -c '1' 2>&- Abandon 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] please consider changing --enable-unicode default to ucs4
Ronald Oussoren: > Both Carbon and the modern APIs use UTF-16. If Unicode size standardization is seen as sufficiently beneficial then UTF-16 would be more widely applicable than UTF-32. Unix mostly uses 8-bit APIs which are either explicitly UTF-8 (such as GTK+) or can accept UTF-8 when the locale is set to UTF-8. They don't accept UTF-32. It is possible that Unix could move towards UTF-32 but that hasn't been the case up to now and with both OS X and Windows being UTF-16, it is more likely that UTF-16 APIs will become more popular on Unix. Neil ___ 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] A new way to configure logging
2009/10/7 Vinay Sajip : > What's the general feeling here about this proposal? All comments and > suggestions will be gratefully received. +1 One option I would have found useful in some code I wrote would be to extend the configuration - class DictConfigurator: ... def extend(self, moreconfig): import copy more = copy.deepcopy(moreconfig) # Not sure if this is needed? self.config.update(more) 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] please consider changing --enable-unicode default to ucs4
On Sun, Sep 20, 2009 at 10:17, Zooko O'Whielacronx wrote: > On Sun, Sep 20, 2009 at 8:27 AM, Antoine Pitrou wrote: >> AFAIK, C extensions should fail loading when they have the wrong UCS2/4 >> setting. > > That would be an improvement! Unfortunately we instead get mysterious > misbehavior of the module, e.g.: > > http://bugs.python.org/setuptools/msg309 > http://allmydata.org/trac/tahoe/ticket/704#comment:5 The real issue here is getting confused because python's option is misnamed. We support UTF-16 and UTF-32, not UCS-2 and UCS-4. This means that when decoding UTF-8, any scalar value outside the BMP will be split into a pair of surrogates on UTF-16 builds; if we were using UCS-2 that'd be an error instead (and *nothing* would understand surrogates.) Yet we are getting an error here. However, if you look at the details you'll notice it's on a 6-byte UTF-8 code unit sequence, corresponding in the second link to U+6E657770. Although the originally UTF-8 left open the possibility of including up to 31 bits (or U+7FFF), this was removed in RFC 3629 and is now strictly prohibited. The modern unicode character set itself also imposes that restriction. There is nothing beyond U+10. Nothing should create a such a high code point, and even if it happened internally a RFC 3629-conformant UTF-8 encoder must refuse to pass it through. Something more subtle must be going on. Possibly several bugs (such as a non-conformant encoder or garbage being misinterpreted as UTF-8). -- Adam Olsen, aka Rhamphoryncus ___ 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] eggs now mandatory for pypi?
On Tue, 06 Oct 2009 16:45:29 +0100, Chris Withers wrote: > Well yeah, and the only sane way I can think to handle this is to have a > metadata file that gets uploaded with each distribution that covers all > these things (and the other things that other people need) and then have > the index (which would hopefully be PyPI on the whole) be queryable > along the lines of "give me a download url for a distribution named X > that is for Python 2.6, Win32, UCS4, PostGreSQL 8.5, BlagBlah"... Exactly. I'd like to see that and it sounds like a very simple and reasonable proposal. One could say that much of the setuptools cloud came about because of the lack of the queryable download url. Setuptools does a lot of work here to 'work-around' the ommission on pypi of a package download url. I'm just with you 100% on this... David ___ 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] A new way to configure logging
On approximately 10/7/2009 7:49 AM, came the following characters from the keyboard of Vinay Sajip: In outline, the scheme I have in mind will look like this, in terms of the new public API: class DictConfigurator: def __init__(self, config): #config is a dict-like object (duck-typed) import copy self.config = copy.deepcopy(config) def configure(self): # actually do the configuration here using self.config dictConfigClass = DictConfigurator def dictConfig(config): dictConfigClass(config).configure() This allows easy replacement of DictConfigurator with a suitable subclass where needed. Concept sounds good, and the idea of separating the syntax of the configuration file from the action of configuring is a clever way of avoiding the "syntax of the (day|platform|environment)" since everyone seems to invent new formats. So people that want to expose a text file to their users have the choice of syntaxes to expose, and then they do logCfg = readMyFavoriteSyntax( logCfgFile ) # or extract a subset of a larger config file for their project DictConfigurator( logCfg ) But DictConfigurator the name seems misleading... like you are configuring how dicts work, rather than how logs work. Maybe with more context this is not a problem, but if it is a standalone class, it is confusing what it does, by name alone. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ 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] A new way to configure logging
Paul Moore gmail.com> writes: > One option I would have found useful in some code I wrote would be to > extend the configuration - > > class DictConfigurator: >... >def extend(self, moreconfig): > import copy > more = copy.deepcopy(moreconfig) # Not sure if this is needed? > self.config.update(more) See my response to Paul Rudin's post about incremental configuration. 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] A new way to configure logging
Glenn Linderman g.nevcal.com> writes: > But DictConfigurator the name seems misleading... like you are > configuring how dicts work, rather than how logs work. Maybe with more > context this is not a problem, but if it is a standalone class, it is > confusing what it does, by name alone. Of course the fully qualified name would be logging.config.DictConfigurator which does provide the requisite context, but if I think of/someone suggests a better name I'll certainly use it. ___ 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 2.6.4rc1
I just tried building out of svn and a ton of tests that rely on urllib failed because the _scproxy module wasn't built and it unconditionally imports it under darwin. Turns out that it requires the Mac toolbox glue to be built which I always skip since I don't care about it. I am fairly certain this toolbox glue dependency for urllib is a regression as I used to always be able to get networking working w/o the Mac-specific modules. -Brett On Wed, Oct 7, 2009 at 10:18, Barry Warsaw wrote: > Hello everyone. > > The source tarballs and Windows installers for Python 2.6.4rc1 are now > available: > > http://www.python.org/download/releases/2.6.4/ > > Please download them, install them, and try to use them with your projects > and environments. Let us know if you encounter any problems with them. > Hopefully we can avoid the situation with 2.6.3 having such critical bugs. > > 2.6.4 final is planned for 18-October. > > 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/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
[Python-Dev] Logging, Unicode and sockets
> Thanks to http://bugs.python.org/issue7077 I've noticed that the socket-based logging handlers - SocketHandler, DatagramHandler and SysLogHandler - aren't Unicode-aware and can break in the presence of Unicode messages. I'd like to fix this by giving these handlers an optional (encoding=None) parameter in their __init__, and then using this to encode on output. If no encoding is specified, is it best to use locale.getpreferredencoding(), sys.getdefaultencoding(), sys.getfilesystemencoding(), 'utf-8' or something else? On my system: >>> sys.getdefaultencoding() 'ascii' >>> sys.getfilesystemencoding() 'mbcs' >>> locale.getpreferredencoding() 'cp1252' which suggests to me that the locale.getpreferredencoding() should be the default. However, as I'm not a Unicode maven, any suggestions would be welcome. 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
