what,
whereas with Python distributions, there's no central authority that has this
function?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
, this data is not considered reliable - for example, pip runs
egg_info on downloaded packages to get updated information when determining
dependencies to be downloaded. If the Requires-Dist info in PKG-INFO can't be
relied on, surely less critical information such as Obso
read the file contents.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
16K, due to the possible presence of a pathologically
large comment in the end record.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
t is
intended to be possible to build packaging systems on top of it. Compared to
distutils2, distlib aims to make it easier to transition from existing
packaging infrastructure and tools (distutils, setuptools/distribute).
Some of the PEPs are still in flux
:O
Actually the BitBucket repo is more active and readthedocs has the latest docs,
but I do periodically update the above repo on hg.python.org.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
Christian Tismer stackless.com> writes:
> Anything I'm missing here?
The use case was missed during PEP and patch review, so the feature didn't make
it into 3.3. Issue #15776 raised the problem; it has been resolved and the
feature should appear in Python 3.4.
Regar
s additional
parameters to GnuPG, and they might use these esoteric GnuPG options.
Regards,
Vinay Sajip
[1]
http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Esoteric-Options.html
___
Python-Dev mailing list
Python-Dev@python.org
http://m
xample where fds other than
0, 1 and 2 might be used by design in not-uncommonly-used programs. From a
discussion I had with Barry Warsaw a while ago, I seem to remember that there
was other software which relied on these features. See [1] for details.
Regards,
Vinay
t supported by PEPs, hence the interest in getting the 3
> wheel PEPs (of which the metadata PEP is the first) accepted.
Likewise, I will look at the possibility of providing wheel support in distlib,
once it has been accepted as a standard and the open issues (such as signature
scheme) have been
ed that distutils2/packaging also failed to make
sufficient progress for the same reason.
Certainly, with distlib I've tried to incorporate a lot of the setuptools
functionality which developers find useful - in-package data, package exports
(entry points), wrapping callables with scripts and
27;t have
the ability to build pure-Python distributions and distributions including C
libs and extensions, with the ability to extend easily by third-party tools. It
just needs to be done in a way which is easy to build on, so the included
battery stays small and simple. Easier said than done, I k
David
is just being self-deprecating, but what if he isn't? Or perhaps that part of
the page is out of date, and needs updating? I can certainly agree with the
"Weak documentation" part of the assessment, but this makes it hard to assess
the package as a whole. Note that I'm not s
David Cournapeau gmail.com> writes:
> You are putting the words out of the context in which those were
> written: it is stated that the focus is on the general architecture
OK, no offence was meant. Thanks for the clarification.
Regards,
Vi
There is already a TimedRotatingFileHandler which will do backups on a
schedule, including daily.
The correct way of doing what you want is to submit a patch via
SourceForge. If the patch is accepted, then your code will end up in Python.
Thanks,
Vinay Sajip
ny other handlers in the stdlib itself, leaving that to
user code. With this approach, by default stdlib code will behave as it does
now. Even the verbose setting of DEBUG on the "py" logger will not produce
any output unless user code sets its propa
Gustavo Niemeyer niemeyer.net> writes:
>
> The StreamHandler available under the logging package is currently
> catching all exceptions under the emit() method call. In the
> Handler.handleError() documentation it's mentioned that it's
> implemented like that because users do not care about erro
ouldn't go into the
release24-maint branch.)
Of course, if anyone can suggest a better way of doing it, I'm all ears :-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
a
key was present rather than absent) be thrown if one of the above attribute
names is supplied as a key in the user-supplied dict.
> Perhaps it makes sense to call it 'extra' instead of 'extra_info'?
Fine - 'extra' it will be.
> As a new feature it shoul
re implementation
details so I don't really want to encourage changing them. If you need to, it's
easy enough to pick up the info from the source code for LogRecord.__init__(),
which does all the setup.
Regards,
Vinay Sajip
___
Python-Dev mai
r
performance you can roll your own LogRecord subclass and do everything inline,
as Skip has mentioned. And if one wants this functionality, and don't check on
every call, when would be a good time to check?
Regards,
Vinay Sajip
___
tom LogRecord initialiser with
the same benefit as in the general case (I think).
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opt
ble to false to avoid expensive
thread and process computations where not needed. The 'extra' mechanism will
remain to provide additional diagnostic information where e.g. the same code is
executed by multiple threads and there is a need to distinguish the different
threads in the logging
example,
http://docs.python.org/lib/module-logging.html has a list of 12 handlers,
followed by a statement to the effect that all but StreamHandler and
FileHandler are defined in the handlers module.
In general, patches are gratefully received! If you don't want to invest
inner" picked (I'm not sure who would do this, or when it
would be done). I'll readily declare an interest - I've implemented an
alternative hierarchical config module (which is in no way backward compatible
with ConfigParser), see
http://www.red-dove.com/python_config.html
Rega
#x27;t have to implement INI support.
What I'd like to know is, what happens how? There are a whole lot of
alternatives put forward in the ConfigParserShootout wiki page, but how do we
move things forward from here?
Regards,
Vinay Sajip
__
ule? After all, they seem for the most part to be well-known
constant strings that don't need to be encapsulated in any particular C
compilation unit.
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe
rget is very important for keeping public API as small as possible.
I'm not suggesting that _Py_IDENTIFIERs become part of the public API. Surely
it's not the case that any and every extern identifier becomes part of the
public API? (I know people can misuse things and use unsuppo
es this discipline/approach not apply to CPython?
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message
> Moving some of the especially common identifier references into the
> interpreter state struct may make sense.
> Adding more process globals wouldn't be desirable though, as they're one of
> the more common ways of breaking encapsulation between subinterpreters
> (hence Eric's efforts to eliminat
esumably, a PEP would be required, even
though it's an implementation detail from the point of view of the language
itself?
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...
s it's still
work in progress - which is why I'm asking these questions.
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailm
ef. I will
check when I get a chance.
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archiv
Ah - I checked, and it's there OK ... (head scratch)
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.pytho
OK - but that's just one I picked at random. There are others like it - what
would be the process for deciding which ones need to be made private and moved?
Should an issue be raised to track this?
Regards,
Vinay Sajip
___
Python-Dev mailing
Fair enough. Pull request created:
https://github.com/python/cpython/pull/16347
Regards,
Vinay Sajip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3
are, of course,
garbage collected in the normal way and so impose no particular memory
burden.
I'll wait a few days for any comments/suggestions from this list, then
(assuming no adverse comments) go ahead and add the LoggerAdapter class and
401 - 437 of 437 matches
Mail list logo
