>
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)
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 th
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
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?
>
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)
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 (
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 th
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, moreco
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 l
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 destru
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
provid
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
unconditio
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
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
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 t
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 r
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
> thei
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
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 ma
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
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
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
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 sa
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
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 implementa
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 bui
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.
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 dis
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
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
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
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
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
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
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
Python-Dev@python.org
http://mail.python.org/mailm
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
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, an
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'
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 m
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 opport
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
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 win
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 th
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
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 co
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 beli
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 pre
+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
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 d
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 fo
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 lik
> 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 f
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
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
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 t
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
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 getLogg
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
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 sta
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
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
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
62 matches
Mail list logo
