my apologies, i found the issue "closed" after doing a search for my
own work, requiring (again) the telnetlib code for yet another
project.
since 2001, the work done has been reimplemented time and time again,
by different individuals, in different projects, in different ways,
all solving exactly the same issues, providing exactly the same type
of functionality, as that provided by TelnetPopen3. e.g. Pexpect is
the one i found today, listed off of
http://en.wikipedia.org/wiki/Expect
l.
Stefan Behnel wrote:
> M.-A. Lemburg wrote:
>> If you use PyBytes APIs, you expect to find PyBytes functions in
>> the libs and also set breakpoints on these.
>
> AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem here.
The PyBytes_* functions appear to be there, but a preprocessor macro
means it is actually the PyString_* functions that appear in the Python
DLL. That's great from a backwards compatibility point of view, but
seriously confusing from the point of view of anyone trying to embed or
otherwise debug Python 2.6.
> Besides, how likely is it that users set a breakpoint on the PyBytes/PyString
> functions?
Not very likely at all - but it would still be nice if the PyBytes_*
symbols were visible to the linker as well as the preprocessor.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
Stefan Behnel schrieb:
> Christian Heimes wrote:
>> * add a new file stringobject.h which contains the aliases PyString_ ->
>> PyBytes_
>
> Just a quick note that that file is still missing from SVN, so it's kind of
> hard to compile existing code against the current branch state...
No, the file is in SVN. It's just not in the py3k branch because it's
not vital to the core.
I had plans to add a Python 2.x compatibility header to Python 3.0 But
I'm not going to spend any more time on the topic or any other
development until we have reached an agreement on the naming. I don't
want to waste more of my free time in vain.
Christian
Stefan Behnel schrieb:
> M.-A. Lemburg wrote:
>> If you use PyBytes APIs, you expect to find PyBytes functions in
>> the libs and also set breakpoints on these.
>
> AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem here.
In Python 2.6 the PyBytes_* functions are only available to the compiler
but not to the linker. In 2.6 the ABI functions are PyString_* and in
3.0 it's PyBytes_*
Christian
[reposting this to python-dev, as it affects both 2.6 and 3.0]
Hi,
when we build extension classes in Cython, we have to first build the type to
make it available to user code, and then update the type's tp_dict while we
run the class body code (PyObject_SetAttr() does not work here). In Py2.6+,
this requires invalidating the method cache after each attribute change, which
Python does internally using the type_modified() function.
Could this function get a public interface? I do not think Cython is the only
case where C code wants to modify a type after its creation, and copying the
code over seems like a hack to me.
Stefan
On Wed, May 28, 2008 at 10:08 AM, Bill Janssen <janssen(a)parc.com> wrote:
>> I'm beginning to wonder whether I'm the only one who cares about
>> the Python 2.x branch not getting cluttered up with artifacts caused
>> by a broken forward merge strategy.
>
> I share your concern. Seems to me that perhaps (not sure, but
> perhaps) the rush to back-port from 3.x, and the concern about
> minimizing pain of moving from 2.x to 3.x, has become the tail wagging
> the dog.
>
Speaking for myself, I know that if fixing something in 2.x means a
pain in forward-porting, I will just do it in 3.x and leave it someone
else to back-port to 2.x which will lower the chances of the back-port
ever occurring. I don't want to do this, but I am fighting damn hard
against burn-out at this point and if I have to choose between
complete burn-out and only working on the leading edge version of
Python, I will choose the latter. So I for one appreciate Christian
taking all of us into account in terms of the approach taken to make
our lives easier when we work on Python.
-Brett
I've noticed that some classes in Cookies module (namely SerialCookie and
SmartCookie) deprecated since 2.3 still present in Python3000 documentation.
http://docs.python.org/dev/3.0/library/http.cookies.html
Is it because ... ?:
1. Docs are not synchronized with API
2. Classes are not removed yet
(http://wiki.python.org/moin/Py3kDeprecatedis actually a TODO)
3. Manual reference should contain information about all historical API
changes
--
--anatoly t.
One of the tasks where classic classes are currently far superior to
new-style classes is in writing proxy classes like weakref.proxy - cases
where nearly all operations need to be delegated to some other object,
with only a few being handled via the proxy type object itself.
With classic classes, this is trivial, since __getattr__ is always
consulted, even for retrieval of special methods.
With new-style classes, however, the __getattribute__ machinery can be
bypassed, meaning the only way to proxy an arbitrary instance is to
define all of the special methods that have C-level slots.
This issue was actually first raised five and a half years ago [1], but
has never been a particularly pressing problem, as anyone with any sense
that needed to write a proxy object just used a classic class instead of
a new-style one. In 3.0, with the demise of classic classes, that
workaround goes away.
So what do people think of including a ProxyBase implementation in 2.6
and 3.0 that explicitly delegates all of the C-level slots to a
designated target instance? For some proxy class implementers, it would
be possible to use this class as a base-class to get the special method
delegation 'for free', and for others with more esoteric needs, it would
at least provide a reference for which special methods needed to be
provided explicitly by the proxy type.
I attached a sample implementation to [1] which is essentially
equivalent to weakref.proxy, but with a strong reference to the target,
and written in Python rather than C.
I expect the target audience for such a feature to be quite small, but
without better support for it in the standard library, I also suspect it
could prove to be a show-stopper for the affected developers as far as
Py3k migration is concerned.
Cheers,
Nick.
[1] http://bugs.python.org/issue643841
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
> Steven D'Aprano" <limeguin(a)pearwood.info>
> If built-in objects grew an __atomic__ attribute, you could
> simplify the atomic() function greatly:
I may not have been clear enough in my previous post.
Atomicity is not an intrinsic property of an object or class.
How could you know in advance what various applications
would want to consider atomic? The decision is application
specific and best left to the caller of the flattener:
def flatten(obj, predicate=None):
if predicate is not None and predicate(obj):
yield obj
else:
for item in obj:
for i in flatten(item):
yield i
> However atomic() is defined, now flatten() is easy:
Rule of thumb: if you find a need to change the language
(adding a new builtin, adding a new protocol, and adding a
property to every builtin and pure python container) just to
implement a simple recipe, then it is the recipe that needs fixing,
not the language.
Raymond
P.S. You're on the right track by factoring the decision
away from the internals of flatten(); however, the atomic()
predicate needs to be user definable for a given application
not hardwired into the language itself.
On 2008-05-27 12:56, Thomas Heller wrote:
> M.-A. Lemburg schrieb:
>> On 2008-05-26 23:34, Christian Heimes wrote:
>>> M.-A. Lemburg schrieb:
>>>> Isn't that an awefuly confusing approach ?
>>>>
>>>> Wouldn't it be better to keep PyString APIs and definitions in
>>>> stringobject.c|h and only add a new bytesobject.h header file
>>>> that #defines the PyBytes APIs in terms of PyString APIs ? That
>>>> maintains backwards compatibility and allows Python internals to
>>>> use the new API names.
>>>>
>>>> With your approach, you've basically backported the confusing
>>>> notion in Py3k that str() maps PyUnicode, only that in Py2 str()
>>>> will now map to PyBytes.
>>> The last time I brought up the topic, I had a lengthy discussion
>>> with Guido. At first I wanted to rename the API in Python 3.0 only.
>>> Guido argued that it's going to cause too much merge conflicts. He
>>> then suggested the approach I implemented today.
>> That's the same argument that came up in the module renaming
>> discussion.
>>
>> I have a feeling that we should be looking for better merge tools,
>> rather than implement code changes that cause more trouble than do
>> good, just because our existing tools aren't smart enough.
>
> There are applications out there that dynamically import the python dll
> and link to the exported functions by name; they will all break.
The exported APIs still use the old names. Just the source code
versions of the APIs change to the new names and they now live
in different files as well.
> I believe in the past we have been more carefull with changes like these.
> Even when python api functions were turned into cpp macros, we provided
> exported functions for them; for a few examples see the function definitions
> near line 1778 in file Python/pythonrun.c .
IMO, we should keep using that strategy for Python 2.x.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, May 27 2008)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania 40 days to go
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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
