Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now

[Martin v. Löwis]

>  ok, there's a solution for that - the gist of the solution is already
> implemented in things like Apache Runtime and Apache2 (modules), and
> is an extremely common standard technique implemented in OS kernels.
> the "old school" name for it is "vector tables".

We might be able to do that in Python 4; it would certainly require
a PEP.

>> No, Python 2.5 is linked with msvcr71.dll.
> 
>  ehn? i don't see that anywhere in any PC/* files - i do see that
> there's a dependency on .NET SDK 1.1 which uses msvcr71.dll

Take a look at PCbuild/pythoncore.vcproj. It says

Version="7.10"

This is how you know VS 2003 was used to build Python 2.5, which
in turn links in msvcr71.dll.

Regards,
Martin
___
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

Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now

[Martin v. Löwis]

>  ironically, i started out with the intent of going for python2N.dll
> interoperability.  then i noticed that all the other mingw ports
> dropped the total-inclusion-of-all-modules  because you _can_.

What modules are built in and what modules are external doesn't affect
interoperability wrt. (third-party) extension modules.

Regards,
Martin
___
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

Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now

[Luke Kenneth Casson Leighton]

On Fri, Jan 23, 2009 at 8:08 AM, "Martin v. Löwis"  wrote:
>>  ironically, i started out with the intent of going for python2N.dll
>> interoperability.  then i noticed that all the other mingw ports
>> dropped the total-inclusion-of-all-modules  because you _can_.
>
> What modules are built in and what modules are external doesn't affect
> interoperability wrt. (third-party) extension modules.

 ahhh  sooo [said in a japanese kind of way that indicates
understanding...]
___
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

Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?

[Martin v. Löwis]

Giampaolo Rodola' wrote:
> Hi,
> while attempting to port pyftpdlib [1] to Python 3 I have noticed that
> ftplib differs from the previous 2.x version in that it uses latin-1
> to encode everything it's sent over the FTP command channel, but by
> reading RFC-2640 [2] it seems that UTF-8 should be preferred instead.
> I'm far from being an expert of encodings, plus the RFC is quite hard
> to understand, so sorry in advance if I have misunderstood the whole
> thing.

I read it that a conforming client MUST issue a FEAT command, to
determine whether the server supports UTF8. One would have to go
back to the original FTP RFC, but it seams that, in the absence
of server UTF8 support, all path names must be 7-bit clean (which
means that ASCII should be the default encoding).

In any case, Brett changed the encoding to latin1 in r58378, maybe
he can comment.

Regards,
Martin
___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Martin v. Löwis]

> And I would like to thank my co-authors for their time and effort thus
> far in filling in the PEP on behalf of their favorite DVCS. Everyone
> has put in a lot of time already with I am sure more time in the
> future.

So what will happen next? ISTM that the PEP is not complete, since it
doesn't specify a specific DVCS to migrate to (i.e. it wouldn't be
possible to implement the PEP as it stands).

Somebody will have to make a decision. Ultimately, Guido will have to
approve the PEP, but it might be that he refuses to make a choice of
specific DVCS. Traditionally, it is the PEP author who makes all
choices (considering suggestions from the community, of course). So
what DVCS do the PEP authors recommend?

Regards,
Martin
___
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

[Python-Dev] Update on MS Windows CE port

[Ulrich Eckhardt]

Hi!

Just a short update on my porting issues. I tried various things in the 
holidays/vacation, filed several bug reports, got a few patches applied and I 
think the thing is taking shape now. However, I couldn't work on it for the 
past two weeks since I'm just too swamped at work here. I haven't given up 
though!


What still needs work?

The main component that requires porting is the pythoncore project, but that 
port isn't finished yet. I'm using the VS8.0 project files as a base and 
adapted it in the following steps (note that this is preliminary):
0. Check out trunk (i.e. 2.x, not 3.x).
1. Create new project configuration for your CE target and use the win32 one 
as a base.
2. In the preprocessor settings, add these entries:
   UNICODE,_UNICODE,UNDER_CE,_WIN32_WCE=$(CEVER)
3. Try compiling. ;)


What issues are left?

There are two classes of errors you will encounter, those that are related to 
CE itself (like missing errno and other parts of standard C) and those that 
are more general, like assuming TCHAR=char. Those that assume that TCHAR=char 
can also be found with the plain win32 variant by simply adding UNICODE and 
_UNICODE to the preprocessor defines.


What are the future plans?

I'm trying to fix errors in pythoncore one by one and provide separate bug 
reports with patches. Note that there are already several patches in the BTS 
which would merit reviews if you have time, even if it's only a "patch 
applies and doesn't cause regressions".

When I get pythoncore to compile (and be it by disabling a few builtin 
modules), I will try to get the commandline interface to work. Note that IIRC 
there are two commandlines availabel under CE, one is a common cmd.exe, the 
other is called AYGShell or some such. Both will/might require different 
approaches.

Another problem is the fact that there is not just one target platform but a 
potentially infinite number of them, since every CE device can have a 
separate SDK which further might provide different features. This probably 
requires autogenerated build files or some other autoconf-like procedure that 
allows enabling or disabling certain features for builds.


so much for now

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Dirkjan Ochtman]

Martin v. Löwis  v.loewis.de> writes:
> Somebody will have to make a decision. Ultimately, Guido will have to
> approve the PEP, but it might be that he refuses to make a choice of
> specific DVCS. Traditionally, it is the PEP author who makes all
> choices (considering suggestions from the community, of course). So
> what DVCS do the PEP authors recommend?

Brett mentioned in his email that he wasn't ready to make a decision yet, I
think? I also think that the PEP could still use some modifications from people
who have more experience with the DVCSs. I'll probably send in some suggestions
later today.

Cheers,

Dirkjan

___
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

Re: [Python-Dev] __del__ and tp_dealloc in the IO lib

[Giovanni Bajo]

On gio, 2009-01-22 at 18:42 -0800, Guido van Rossum wrote:
> On Thu, Jan 22, 2009 at 5:22 PM, Giovanni Bajo  wrote:
> > CPython will always use reference counting and thus have a simple and
> > clear GC criteria that can be exploited to simplify the code.
> 
> Believe this at your own peril.
> 
> Once, CPython didn't have GC at all (apart from refcounting). Now it
> does. There are GC techniques that delay DECREF operations until it's
> more convenient. If someone finds a way to exploit that technique to
> save 10% of execution time it would only be right to start using it.
> 
> You *can* assume that objects that are no longer referenced will
> *eventually* be GC'ed, and that GC'ing a file means flushing its
> buffer and closing its file descriptor. You *cannot* assume that
> objects are *immediately* GC'ed. This is already not always true in
> CPython for many different reasons, like objects involved in cycles,
> weak references,

I don't understand what you mean with weak references delaying object
deallocation. I'm probably missing something here...

>  or tracebacks saved with exceptions, or perhaps
> profiling/debugging hooks. If we found a good reason to introduce file
> objects into some kind of cycle or weak reference dict, I could see
> file objects getting delayed reclamation even without changes in GC
> implementation.

That would be break so much code that I doubt that, in practice, you can
slip it through within a release. Besides, being able to write simpler
code like "for L in open("foo.txt")" is per-se a good reason *not to*
put file objects in cycles; so you will probably need more than one good
reason to change this. OK, not *you* because of your BDFL powers ;), but
anyone else would surely have to face great opposition.

The fact that file objects are collected and closed immediately in all
reasonable use cases (and even in case of exceptions, that you mention,
things get even better with the new semantic of the except clause) is a
*good* property of Python. I regularly see people *happy* about it.

I miss to understand why many Python developers are so fierce in trying
to push the idea of cross-python compatibility (which is something that
does simply *not* exist in real world for applications) or to warn about
rainy days in the future when this would stop working in CPython. I
would strongly prefer that CPython would settle on (= document) using
reference counting and immediate destruction so that people can stop
making their everyday code more complex with no benefit. You will be
losing no more than an open door that nobody has entered in 20 years,
and people would only benefit from it.
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com


___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Antoine Pitrou]

Brett Cannon  python.org> writes:
> 
> I have now converted PEP 374
> (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST
> and checked it in. I am not going to paste it into an email as it is
> nearly 1500 lines in reST form.

It seems the ">>" token is mangled into a French closing quote ("»") inside code
snippets.


Antoine.


___
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

Re: [Python-Dev] __del__ and tp_dealloc in the IO lib

[Steve Holden]

Giovanni Bajo wrote:
> On gio, 2009-01-22 at 18:42 -0800, Guido van Rossum wrote:
[...]
> I miss to understand why many Python developers are so fierce in trying
> to push the idea of cross-python compatibility (which is something that
> does simply *not* exist in real world for applications) or to warn about
> rainy days in the future when this would stop working in CPython. I
> would strongly prefer that CPython would settle on (= document) using
> reference counting and immediate destruction so that people can stop
> making their everyday code more complex with no benefit. You will be
> losing no more than an open door that nobody has entered in 20 years,
> and people would only benefit from it.

Probably because it's good practice to write for compatibility where
possible. Cross-OS compatibility isn't possible in the general case
either, but it's still a good goal in the cases where it *is* possible.

Given that your sample code will generally work even for implementations
where garbage collection is used rather than reference counting I fail
to understand why you insist so hard that a more restrictive rule should
be implemented.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
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

Re: [Python-Dev] __del__ and tp_dealloc in the IO lib

[Antoine Pitrou]

Giovanni Bajo  develer.com> writes:
> 
> The fact that file objects are collected and closed immediately in all
> reasonable use cases (and even in case of exceptions, that you mention,
> things get even better with the new semantic of the except clause)

The new except clause removes any external references to the exception, but
there's still, AFAIR, the reference cycle through the traceback object, which
means the whole thing will still have to wait for a pass of the cyclic garbage
collector.

Regards

Antoine.


___
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

Re: [Python-Dev] __del__ and tp_dealloc in the IO lib

[Maciej Fijalkowski]

> That would be break so much code that I doubt that, in practice, you can
> slip it through within a release. Besides, being able to write simpler
> code like "for L in open("foo.txt")" is per-se a good reason *not to*
> put file objects in cycles; so you will probably need more than one good
> reason to change this. OK, not *you* because of your BDFL powers ;), but
> anyone else would surely have to face great opposition.

note that this is about *writing* files, not reading. You would be
surprised how much of the software have already taken care to be
cross-platform (ie twisted, django, pylons, ...), not to rely on that
and be able to run on any other python implementation.

>
> The fact that file objects are collected and closed immediately in all
> reasonable use cases (and even in case of exceptions, that you mention,
> things get even better with the new semantic of the except clause) is a
> *good* property of Python. I regularly see people *happy* about it.
>
> I miss to understand why many Python developers are so fierce in trying
> to push the idea of cross-python compatibility (which is something that
> does simply *not* exist in real world for applications) or to warn about
> rainy days in the future when this would stop working in CPython. I
> would strongly prefer that CPython would settle on (= document) using
> reference counting and immediate destruction so that people can stop
> making their everyday code more complex with no benefit. You will be
> losing no more than an open door that nobody has entered in 20 years,
> and people would only benefit from it.

someone said at some point "noone will ever need more than 650k of
RAM". see what has happened.

Cheers,
fijal
___
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

Re: [Python-Dev] __del__ and tp_dealloc in the IO lib

[rdmurray]

On Fri, 23 Jan 2009 at 11:57, Giovanni Bajo wrote:

The fact that file objects are collected and closed immediately in all
reasonable use cases (and even in case of exceptions, that you mention,
things get even better with the new semantic of the except clause) is a
*good* property of Python. I regularly see people *happy* about it.


I have never assumed that python closed my files before the end of the
program unless I told it to do so, and have always coded accordingly.
To do otherwise strikes me as bad coding.  I don't believe I ever
considered that such an assumption was even thinkable:  closing open files
when I'm done with them is part of my set of "good programming" habits
developed over years of coding, habits that I apply in _any_ language in
which I write code.  (In fact, it took me a while before I was willing
to let python take care of closing the files at program end...and even
now I sometimes close files explicitly even in short programs.)

Closing file objects is a specific instance of a more general programming
rule that goes something like "clean up when you are done".  I do in
general trust python to clean up python data structures because it knows
better than I do when "done" arrives; but when I know when "done" is,
I do the cleanup.  I love the 'with' statement :)

--RDM
___
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

Re: [Python-Dev] __del__ and tp_dealloc in the IO lib

[Guido van Rossum]

On Fri, Jan 23, 2009 at 2:57 AM, Giovanni Bajo  wrote:
> I miss to understand why many Python developers are so fierce in trying
> to push the idea of cross-python compatibility (which is something that
> does simply *not* exist in real world for applications) or to warn about
> rainy days in the future when this would stop working in CPython. I
> would strongly prefer that CPython would settle on (= document) using
> reference counting and immediate destruction so that people can stop
> making their everyday code more complex with no benefit. You will be
> losing no more than an open door that nobody has entered in 20 years,
> and people would only benefit from it.

You are so very wrong, my son. CPython's implementation strategy
*will* evolve. Several groups are hard at work trying to make a faster
Python interpreter, and when they succeed, everyone, including you,
will want to use their version (or their version may simply *be* the
new CPython).

Plus, you'd be surprised how many people might want to port existing
code (and that may include code that uses C extensions, many of which
are also ported) to Jython or IronPython.

Your mistake sounds more like "nobody will ever want to run this on
Windows, so I won't have to use the os.path module" and other
short-sighted ideas. While you may be right in the short run, it may
also be the death penalty for a piece of genius code that is found to
be unportable.

And, by the way, "for line in open(filename): ..." will continue to
work. It may just not close the file right away. This is a forgivable
sin in a small program that opens a few files only. It only becomes a
program when this is itself inside a loop that loops over many
filenames -- you could run out of file descriptors.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brett, thanks for putting this PEP together!

On Jan 23, 2009, at 3:39 AM, Martin v. Löwis wrote:


Somebody will have to make a decision. Ultimately, Guido will have to
approve the PEP, but it might be that he refuses to make a choice of
specific DVCS. Traditionally, it is the PEP author who makes all
choices (considering suggestions from the community, of course). So
what DVCS do the PEP authors recommend?


Brett, perhaps you should publish a tentative schedule.  Milestones  
I'd like to see include


* Initial impressions section completed
* Call for rebuttals
* Second draft of impressions
* (perhaps multiple) Recommendations to Guido and python-dev
* Experimental live branches deployed for testing
* Final recommendation
* Final decision

My understanding is that a final decision will /not/ be made by Pycon.

Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSXnis3EjvBPtnXfVAQJTqwQAimSA/JDzYN132npgazIag3fwOk36DAJl
vvYMXOfWqvfl9DO/8cPF9YFOwF7YdHM8k4wUTmfLYhE8JfefODjrdHkL5pdclwDg
Pbb2tjMfl0vBOPeaaPnJ5NKIJMwyRWkVhFMyNU5KmBmVRPJXpAQM23IOORX2dAaI
tLONmrvx8K4=
=CF18
-END PGP SIGNATURE-
___
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

Re: [Python-Dev] __del__ and tp_dealloc in the IO lib

[Giovanni Bajo]

On 1/23/2009 4:27 PM, Guido van Rossum wrote:

On Fri, Jan 23, 2009 at 2:57 AM, Giovanni Bajo  wrote:

I miss to understand why many Python developers are so fierce in trying
to push the idea of cross-python compatibility (which is something that
does simply *not* exist in real world for applications) or to warn about
rainy days in the future when this would stop working in CPython. I
would strongly prefer that CPython would settle on (= document) using
reference counting and immediate destruction so that people can stop
making their everyday code more complex with no benefit. You will be
losing no more than an open door that nobody has entered in 20 years,
and people would only benefit from it.


You are so very wrong, my son. CPython's implementation strategy
*will* evolve. Several groups are hard at work trying to make a faster
Python interpreter, and when they succeed, everyone, including you,
will want to use their version (or their version may simply *be* the
new CPython).


I'm basing my assumption on 19 years of history of CPython. Please, 
correct me if I'm wrong, but the only thing that changed is that the 
cyclic-GC was added so that loops are now collected, but nothing change 
with respect to cyclic collection. And everybody (including you, IIRC) 
has always agreed that it would be very very hard to eradicate reference 
counting from CPython and all the existing extensions; so hard that it 
is probably more convenient to start a different interpreter implementation.



Plus, you'd be surprised how many people might want to port existing
code (and that may include code that uses C extensions, many of which
are also ported) to Jython or IronPython.


I would love to be surprised, in fact!

Since I fail to see any business strategy behind such a porting, I don't 
see this happening very often in the business industry (and even less in 
the open source community, where there are also political issues between 
those versions of Python, I would say). I also never met someone that 
wanted to make a cross-interpreter Python application, nor read about 
someone that has a reasonable use case for wanting to do that, besides 
geek fun; which is why I came to this conclusion, though I obviously 
have access only to a little information compared to other people in here.


On the other hand, I see people using IronPython so that they can access 
to the .NET framework (which can't be ported to other Python versions), 
or using Java so that they can blend to existing Java programs. And 
those are perfectly good use cases for the existence of such 
interpreters, but not for the merits of writing cross-interpreter 
portable code.


I would be pleased if you (or others) could point me to real-world use 
cases of this cross-interpreter portability.



Your mistake sounds more like "nobody will ever want to run this on
Windows, so I won't have to use the os.path module" and other
short-sighted ideas. While you may be right in the short run, it may
also be the death penalty for a piece of genius code that is found to
be unportable.


And in fact, I don't defensively code cross-OS portable code. Python is 
great in that *most* of what you naturally write is portable; which 
means that, the day that you need it, it's a breeze to port your code 
(assuming that you have also picked up the correct extensions, which I 
always try to do). But that does not mean that I have today to waste 
time on something that I don't need.



And, by the way, "for line in open(filename): ..." will continue to
work. It may just not close the file right away. This is a forgivable
sin in a small program that opens a few files only. It only becomes a
program when this is itself inside a loop that loops over many
filenames -- you could run out of file descriptors.


I do understand this, but I'm sure you realize that there other similars 
example where the side effects are far worse. Maybe you don't care since 
you simply decided to declare that code *wrong*. But I'm unsure the 
community will kindly accept such a deep change in behaviour. Especially 
 within the existing 2.x or 3.x release lines.

--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com
___
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

Re: [Python-Dev] __del__ and tp_dealloc in the IO lib

[Antoine Pitrou]

Guido van Rossum  python.org> writes:
> 
> And, by the way, "for line in open(filename): ..." will continue to
> work. It may just not close the file right away. This is a forgivable
> sin in a small program that opens a few files only. It only becomes a
> program when this is itself inside a loop that loops over many
> filenames -- you could run out of file descriptors.

It can also be a problem under Windows where, IIRC, you can't delete a file
which is still opened somewhere (even for reading).



___
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

Re: [Python-Dev] __del__ and tp_dealloc in the IO lib

[Steve Holden]

Giovanni Bajo wrote:
> On 1/23/2009 4:27 PM, Guido van Rossum wrote:
>> On Fri, Jan 23, 2009 at 2:57 AM, Giovanni Bajo  wrote:
>>> I miss to understand why many Python developers are so fierce in trying
>>> to push the idea of cross-python compatibility (which is something that
>>> does simply *not* exist in real world for applications) or to warn about
>>> rainy days in the future when this would stop working in CPython. I
>>> would strongly prefer that CPython would settle on (= document) using
>>> reference counting and immediate destruction so that people can stop
>>> making their everyday code more complex with no benefit. You will be
>>> losing no more than an open door that nobody has entered in 20 years,
>>> and people would only benefit from it.
>>
>> You are so very wrong, my son. CPython's implementation strategy
>> *will* evolve. Several groups are hard at work trying to make a faster
>> Python interpreter, and when they succeed, everyone, including you,
>> will want to use their version (or their version may simply *be* the
>> new CPython).
> 
> I'm basing my assumption on 19 years of history of CPython. Please,
> correct me if I'm wrong, but the only thing that changed is that the
> cyclic-GC was added so that loops are now collected, but nothing change
> with respect to cyclic collection. And everybody (including you, IIRC)
> has always agreed that it would be very very hard to eradicate reference
> counting from CPython and all the existing extensions; so hard that it
> is probably more convenient to start a different interpreter
> implementation.
> 
And everybody knows that the past is an infallible guide to the future
... not.

>> Plus, you'd be surprised how many people might want to port existing
>> code (and that may include code that uses C extensions, many of which
>> are also ported) to Jython or IronPython.
> 
> I would love to be surprised, in fact!
> 
Well both Django and Twisted are on the list of "interested in porting".

> Since I fail to see any business strategy behind such a porting, I don't
> see this happening very often in the business industry (and even less in
> the open source community, where there are also political issues between
> those versions of Python, I would say). I also never met someone that
> wanted to make a cross-interpreter Python application, nor read about
> someone that has a reasonable use case for wanting to do that, besides
> geek fun; which is why I came to this conclusion, though I obviously
> have access only to a little information compared to other people in here.
> 
Exactly.

> On the other hand, I see people using IronPython so that they can access
> to the .NET framework (which can't be ported to other Python versions),
> or using Java so that they can blend to existing Java programs. And
> those are perfectly good use cases for the existence of such
> interpreters, but not for the merits of writing cross-interpreter
> portable code.
> 
Well, they use IronPython so they can access the .NET framework FROM
PYTHON. Would you willfully isolate those users from access to other
Python code?

> I would be pleased if you (or others) could point me to real-world use
> cases of this cross-interpreter portability.
> 
Any code that *can* be run on multiple interpreters is a candidate for
use in multiple environments. I don't understand this wish to cripple
your code.

>> Your mistake sounds more like "nobody will ever want to run this on
>> Windows, so I won't have to use the os.path module" and other
>> short-sighted ideas. While you may be right in the short run, it may
>> also be the death penalty for a piece of genius code that is found to
>> be unportable.
> 
> And in fact, I don't defensively code cross-OS portable code. Python is
> great in that *most* of what you naturally write is portable; which
> means that, the day that you need it, it's a breeze to port your code
> (assuming that you have also picked up the correct extensions, which I
> always try to do). But that does not mean that I have today to waste
> time on something that I don't need.
> 
Perhaps not, but just because you assess it to be a YAGNI in your own
case that doesn't mean the same arguments should be applied to (for
example) standard library modules.

>> And, by the way, "for line in open(filename): ..." will continue to
>> work. It may just not close the file right away. This is a forgivable
>> sin in a small program that opens a few files only. It only becomes a
>> program when this is itself inside a loop that loops over many
>> filenames -- you could run out of file descriptors.
> 
> I do understand this, but I'm sure you realize that there other similars
> example where the side effects are far worse. Maybe you don't care since
> you simply decided to declare that code *wrong*. But I'm unsure the
> community will kindly accept such a deep change in behaviour. Especially
>  within the existing 2.x or 3.x release lines.

The community is, I suspect, more in line with Gu

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (01/16/09 - 01/23/09)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2322 open (+42) / 14538 closed (+32) / 16860 total (+74)

Open issues with patches:   790

Average duration of open issues: 701 days.
Median duration of open issues:   6 days.

Open Issues Breakdown
   open  2299 (+42)
pending23 ( +0)

Issues Created Or Reopened (79)
___

Unpickling is really slow01/18/09
   http://bugs.python.org/issue3873reopened pitrou
   

zipfile and winzip   01/17/09
   http://bugs.python.org/issue3997reopened pitrou
   patch, needs review 

Thread Safe Py_AddPendingCall01/16/09
CLOSED http://bugs.python.org/issue4293reopened marketdickinson   
   patch, patch

python3.0 -u: unbuffered stdout  01/19/09
   http://bugs.python.org/issue4705reopened pitrou
   patch   

decoding functions in _codecs module accept str arguments01/22/09
CLOSED http://bugs.python.org/issue4874reopened pitrou
   patch   

UTF-16 stream codec barfs on valid input 01/16/09
CLOSED http://bugs.python.org/issue4964created  gvanrossum
   

Can doc index of html version be separately scrollable?  01/16/09
   http://bugs.python.org/issue4965created  tjreedy   
   

Improving Lib Doc Sequence Types Section 01/16/09
   http://bugs.python.org/issue4966created  tjreedy   
   

Bugs in _ssl object read() when a buffer is specified01/17/09
   http://bugs.python.org/issue4967created  pitrou
   patch   

Clarify inspect.is method docs 01/17/09
   http://bugs.python.org/issue4968created  tjreedy   
   

mimetypes on Windows should read MIME database from registry (w/ 01/17/09
   http://bugs.python.org/issue4969created  gagenellina   
   patch   

test_os causes delayed failure on x86 gentoo buildbot: Unknown s 01/17/09
   http://bugs.python.org/issue4970created  marketdickinson   
   

Incorrect title case 01/17/09
   http://bugs.python.org/issue4971created  mrabarnett
   

let's equip ftplib.FTP with __enter__ and __exit__   01/17/09
   http://bugs.python.org/issue4972created  tarek 
   patch   

calendar formatyearpage returns bytes, not str   01/17/09
   http://bugs.python.org/issue4973created  mnewman   
   

Redundant mention of lists and tuples at start of Sequence Types 01/17/09
CLOSED http://bugs.python.org/issue4974created  MLModel   
   

3.0 base64 doc examples lack bytes 'b' indicator 01/17/09
CLOSED http://bugs.python.org/issue4975created  tjreedy   
   

Documentation of the set intersection and difference operators i 01/17/09
CLOSED http://bugs.python.org/issue4976created  MLModel   
   

test_maxint64 fails on 32-bit systems due to assumption that 64- 01/20/09
   http://bugs.python.org/issue4977reopened pitrou
   

allow unicode keyword args   

Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?

[Brett Cannon]

On Fri, Jan 23, 2009 at 00:31, "Martin v. Löwis"  wrote:
> Giampaolo Rodola' wrote:
>> Hi,
>> while attempting to port pyftpdlib [1] to Python 3 I have noticed that
>> ftplib differs from the previous 2.x version in that it uses latin-1
>> to encode everything it's sent over the FTP command channel, but by
>> reading RFC-2640 [2] it seems that UTF-8 should be preferred instead.
>> I'm far from being an expert of encodings, plus the RFC is quite hard
>> to understand, so sorry in advance if I have misunderstood the whole
>> thing.
>
> I read it that a conforming client MUST issue a FEAT command, to
> determine whether the server supports UTF8. One would have to go
> back to the original FTP RFC, but it seams that, in the absence
> of server UTF8 support, all path names must be 7-bit clean (which
> means that ASCII should be the default encoding).
>
> In any case, Brett changed the encoding to latin1 in r58378, maybe
> he can comment.
>

If I remember correctly something along Martin's comment about 7-bit
clean is needed, but some servers don't follow the standard, so I
swapped it to Latin-1. But that was so long ago I don't remember where
I gleaned the details from in the RFC. If I misread the RFC and it is
UTF-8 then all the better to make more of the world move over to
Unicode.

-Brett
___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Brett Cannon]

On Fri, Jan 23, 2009 at 00:39, "Martin v. Löwis"  wrote:
>> And I would like to thank my co-authors for their time and effort thus
>> far in filling in the PEP on behalf of their favorite DVCS. Everyone
>> has put in a lot of time already with I am sure more time in the
>> future.
>
> So what will happen next? ISTM that the PEP is not complete, since it
> doesn't specify a specific DVCS to migrate to (i.e. it wouldn't be
> possible to implement the PEP as it stands).
>

Right, it isn't done. But I know from experience people care A LOT
about their favorite DVCS, so I wanted to get the PEP up now so people
can start sending in feedback to the proper authors instead of having
it all flood in after I have done my exploratory work on all of them
and be accused of having based my decision on faulty information.

> Somebody will have to make a decision.

That falls on my shoulders.

> Ultimately, Guido will have to
> approve the PEP, but it might be that he refuses to make a choice of
> specific DVCS.

Guido is staying out of this one.

> Traditionally, it is the PEP author who makes all
> choices (considering suggestions from the community, of course). So
> what DVCS do the PEP authors recommend?

Umm::

import random
print(random.choice('svn', 'bzr', 'hg', 'git'))

-Brett
___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Brett Cannon]

On Fri, Jan 23, 2009 at 03:05, Antoine Pitrou  wrote:
> Brett Cannon  python.org> writes:
>>
>> I have now converted PEP 374
>> (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST
>> and checked it in. I am not going to paste it into an email as it is
>> nearly 1500 lines in reST form.
>
> It seems the ">>" token is mangled into a French closing quote ("»") inside 
> code
> snippets.

Yeah, the Google Docs export didn't come out well in pure text. I
tried to catch as many of those characters as I could but apparently I
missed a couple.

-Brett
___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Brett Cannon]

On Fri, Jan 23, 2009 at 07:30, Barry Warsaw  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Brett, thanks for putting this PEP together!
>

Yep. Just make sure I don't do something like this for a LONG time.
Apparently I didn't learn my lesson after the issue tracker migration.

> On Jan 23, 2009, at 3:39 AM, Martin v. Löwis wrote:
>
>> Somebody will have to make a decision. Ultimately, Guido will have to
>> approve the PEP, but it might be that he refuses to make a choice of
>> specific DVCS. Traditionally, it is the PEP author who makes all
>> choices (considering suggestions from the community, of course). So
>> what DVCS do the PEP authors recommend?
>
> Brett, perhaps you should publish a tentative schedule.  Milestones I'd like
> to see include
>
> * Initial impressions section completed
> * Call for rebuttals
> * Second draft of impressions
> * (perhaps multiple) Recommendations to Guido and python-dev
> * Experimental live branches deployed for testing
> * Final recommendation
> * Final decision
>

I think you just published the schedule, Barry. =) Seriously, though,
I have several other commitments that take precedent over this PEP so
I don't feel comfortable locking down any dates.

> My understanding is that a final decision will /not/ be made by Pycon.

It's doubtful, but would be nice by then. What I will do is eliminate
a contender by/at PyCon.

-Brett
___
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

Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?

[Oleg Broytmann]

On Fri, Jan 23, 2009 at 10:15:18AM -0800, Brett Cannon wrote:
> If I remember correctly something along Martin's comment about 7-bit
> clean is needed, but some servers don't follow the standard, so I
> swapped it to Latin-1. But that was so long ago I don't remember where
> I gleaned the details from in the RFC. If I misread the RFC and it is
> UTF-8 then all the better to make more of the world move over to
> Unicode.

   I don't know any server that encode file names in any way. All servers
I know just pass filenames as is, 8-bit; some that implement stricter
RFC-959 mangle chr(255), but that's all. One can encounter a server that
stores files in a number of different encodings.

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
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

[Python-Dev] Fwd: [ALERT] cbank: OldHashChecker cannot check password, uid is None

[Tony Lownds]

Rob and/or Tim,

Can you track this down?

Thanks
-Tony

Begin forwarded message:


From: support+...@pagedna.com
Date: January 23, 2009 11:16:26 AM PST
To: probl...@pagedna.com
Subject: [ALERT] cbank: OldHashChecker cannot check password, uid is  
None


OldHashChecker cannot check password, uid is None
Script: /inet/www/clients/cbank/index.cgi
Machine: siteserver3
Directory: /mnt/sitenfs2_clients/cbank



___
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

Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?

[rdmurray]

On Fri, 23 Jan 2009 at 21:55, Oleg Broytmann wrote:

On Fri, Jan 23, 2009 at 10:15:18AM -0800, Brett Cannon wrote:

If I remember correctly something along Martin's comment about 7-bit
clean is needed, but some servers don't follow the standard, so I
swapped it to Latin-1. But that was so long ago I don't remember where
I gleaned the details from in the RFC. If I misread the RFC and it is
UTF-8 then all the better to make more of the world move over to
Unicode.


  I don't know any server that encode file names in any way. All servers
I know just pass filenames as is, 8-bit; some that implement stricter
RFC-959 mangle chr(255), but that's all. One can encounter a server that
stores files in a number of different encodings.


Given that a Unix OS can't know what encoding a filename is in (*),
I can't see that one could practically implement a Unix FTP server
in any other way.

--RDM

(*) remember the earlier extensive discussion of this when the issue
of listdir() ignoring non-encodable filesnames came up?
___
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

Re: [Python-Dev] Fwd: [ALERT] cbank: OldHashChecker cannot check password, uid is None

[Brett Cannon]

Uh, Tony, I think you sent this to the wrong email address.  =)

On Fri, Jan 23, 2009 at 11:22, Tony Lownds  wrote:
> Rob and/or Tim,
> Can you track this down?
> Thanks
> -Tony
>
> Begin forwarded message:
>
> From: support+...@pagedna.com
> Date: January 23, 2009 11:16:26 AM PST
> To: probl...@pagedna.com
> Subject: [ALERT] cbank: OldHashChecker cannot check password, uid is None
> OldHashChecker cannot check password, uid is None
> Script: /inet/www/clients/cbank/index.cgi
> Machine: siteserver3
> Directory: /mnt/sitenfs2_clients/cbank
>
>
>
> ___
> 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/brett%40python.org
>
>
___
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

[Python-Dev] Fwd: [ALERT] cityoftoronto: problem saving to products table

[Tony Lownds]

Hi Paulus,

Have you fixed these aerts before? We need a script to fix these alerts.

Thanks
-Tony

Begin forwarded message:


From: support+...@pagedna.com
Date: January 23, 2009 11:00:01 AM PST
To: probl...@pagedna.com
Subject: [ALERT] cityoftoronto: problem saving to products table

problem saving to products table

Traceback (most recent call last):
 File "/opt/printra/lib/python/printra/sossite/KindManager.py", line  
325, in save_to_products_table

   self.save_to_products_table2(kinds)
 File "/opt/printra/lib/python/printra/sossite/KindManager.py", line  
344, in save_to_products_table2

   if dbkind.update(site, kind):
 File "/opt/printra/lib/python/printra/sossite/KindManager.py", line  
490, in update

   v = fn(kind)
 File "/opt/printra/lib/python/printra/sossite/KindManager.py", line  
474, in _buy_price

   return coerce_qtyspec(kind.buy_qtyspec).price_for_qty(1)
 File "/opt/printra/lib/python/printra/sossite/Sos2qtyspec.py", line  
778, in price_for_qty

   q, p, l = _qtypricesplit(q)
 File "/opt/printra/lib/python/printra/sossite/Sos2qtyspec.py", line  
671, in _qtypricesplit

   raise ValueError, "bad tuple to qtyonly: %s" % t
ValueError: bad tuple to qtyonly: [(1000, '1000 - $67.42'), (6000,  
'6000 - $356.52'), (1, '1 - $486.2')]


Menu user: rolando
Script: /inet/www/clients/cityoftoronto/index.cgi
Machine: siteserver3
Directory: /mnt/sitenfs2_clients/cityoftoronto



___
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

Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?

[Oleg Broytmann]

On Fri, Jan 23, 2009 at 02:35:01PM -0500, rdmur...@bitdance.com wrote:
> Given that a Unix OS can't know what encoding a filename is in (*),
> I can't see that one could practically implement a Unix FTP server
> in any other way.

   Can you believe there is a well-known program that solved the issue?! It
is Apache web server! One can configure different directories and different
file types to have different encodings. I often do that. One (sysadmin) can
even allow users to do the configuration themselves via .htaccess local files.
   I am pretty sure FTP servers could borrow some ideas from Apache in this
area. But they don't. Pity. :(

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
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

Re: [Python-Dev] Fwd: [ALERT] cityoftoronto: problem saving to products table

[Guido van Rossum]

Tony, you are posting internal communications to python-dev!!!

On Fri, Jan 23, 2009 at 11:09 AM, Tony Lownds  wrote:
> Hi Paulus,
> Have you fixed these aerts before? We need a script to fix these alerts.
> Thanks
> -Tony
>
> Begin forwarded message:
>
> From: support+...@pagedna.com
> Date: January 23, 2009 11:00:01 AM PST
> To: probl...@pagedna.com
> Subject: [ALERT] cityoftoronto: problem saving to products table
> problem saving to products table
>
> Traceback (most recent call last):
>  File "/opt/printra/lib/python/printra/sossite/KindManager.py", line 325, in
> save_to_products_table
>self.save_to_products_table2(kinds)
>  File "/opt/printra/lib/python/printra/sossite/KindManager.py", line 344, in
> save_to_products_table2
>if dbkind.update(site, kind):
>  File "/opt/printra/lib/python/printra/sossite/KindManager.py", line 490, in
> update
>v = fn(kind)
>  File "/opt/printra/lib/python/printra/sossite/KindManager.py", line 474, in
> _buy_price
>return coerce_qtyspec(kind.buy_qtyspec).price_for_qty(1)
>  File "/opt/printra/lib/python/printra/sossite/Sos2qtyspec.py", line 778, in
> price_for_qty
>q, p, l = _qtypricesplit(q)
>  File "/opt/printra/lib/python/printra/sossite/Sos2qtyspec.py", line 671, in
> _qtypricesplit
>raise ValueError, "bad tuple to qtyonly: %s" % t
> ValueError: bad tuple to qtyonly: [(1000, '1000 - $67.42'), (6000, '6000 -
> $356.52'), (1, '1 - $486.2')]
>
> Menu user: rolando
> Script: /inet/www/clients/cityoftoronto/index.cgi
> Machine: siteserver3
> Directory: /mnt/sitenfs2_clients/cityoftoronto
>
>
>
> ___
> 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/guido%40python.org
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?

[Toshio Kuratomi]

Oleg Broytmann wrote:
> On Fri, Jan 23, 2009 at 02:35:01PM -0500, rdmur...@bitdance.com wrote:
>> Given that a Unix OS can't know what encoding a filename is in (*),
>> I can't see that one could practically implement a Unix FTP server
>> in any other way.
> 
>Can you believe there is a well-known program that solved the issue?! It
> is Apache web server! One can configure different directories and different
> file types to have different encodings. I often do that. One (sysadmin) can
> even allow users to do the configuration themselves via .htaccess local files.
>I am pretty sure FTP servers could borrow some ideas from Apache in this
> area. But they don't. Pity. :(
> 
AFAIK, Apache is in the same boat as ftp servers.  You're thinking of
the encoding inside of the files.  The problem is with the file names
themselves.

-Toshio



signature.asc
Description: OpenPGP digital signature
___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Martin v. Löwis]

> import random
> print(random.choice('svn', 'bzr', 'hg', 'git'))

Nice! So it's bzr, as my machine just told me (after adding
the square brackets).

Regards,
Martin
___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Steven Bethard]

On Fri, Jan 23, 2009 at 12:06 PM, "Martin v. Löwis"  wrote:
>> import random
>> print(random.choice('svn', 'bzr', 'hg', 'git'))
>
> Nice! So it's bzr, as my machine just told me (after adding
> the square brackets).

Wow, that decision was a lot easier than I thought it would be. ;-)

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Brett Cannon]

On Fri, Jan 23, 2009 at 12:11, Steven Bethard  wrote:
> On Fri, Jan 23, 2009 at 12:06 PM, "Martin v. Löwis"  
> wrote:
>>> import random
>>> print(random.choice('svn', 'bzr', 'hg', 'git'))
>>
>> Nice! So it's bzr, as my machine just told me (after adding
>> the square brackets).
>
> Wow, that decision was a lot easier than I thought it would be. ;-)

But my machine just told me svn, which is even easier as that means we
don't need to change anything. =)

-Brett
___
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

Re: [Python-Dev] Update on MS Windows CE port

[Martin v. Löwis]

> Just a short update on my porting issues. I tried various things in the 
> holidays/vacation, filed several bug reports, got a few patches applied and I 
> think the thing is taking shape now. However, I couldn't work on it for the 
> past two weeks since I'm just too swamped at work here. I haven't given up 
> though!

Thanks for the update.

I can only say: Ready when you are. I'm doubtful that anybody will
continue to work on this (at least not in the same direction that
you took). So whenever you chose to return, it's likely still where
you left off (with some of the code having rot).

Regards,
Martin
___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Martin v. Löwis]

> Brett mentioned in his email that he wasn't ready to make a decision yet, I
> think? I also think that the PEP could still use some modifications from 
> people
> who have more experience with the DVCSs.

My question really was whether it is already ready for the wider
audience up for discussion (and if so, what it is that should be
discussed). It seems that it's not the case, so I just sit back and wait
until its ready.

Regards,
Martin
___
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

Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?

[Martin v. Löwis]

> Given that a Unix OS can't know what encoding a filename is in (*),
> I can't see that one could practically implement a Unix FTP server
> in any other way.

However, an ftp server is different. It might start up with an empty
folder, and receive *all* of its files through upload. Then it can
certainly know what encoding the file names have on disk. It *could*
also support operation on pre-existing files, e.g. by providing a
configuration directive telling the encoding of the file names, or
by ignoring all file names that are not encoded in UTF-8.

Regards,
Martin
___
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

Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?

[Oleg Broytmann]

On Fri, Jan 23, 2009 at 11:54:38AM -0800, Toshio Kuratomi wrote:
> AFAIK, Apache is in the same boat as ftp servers.  You're thinking of
> the encoding inside of the files.  The problem is with the file names
> themselves.

   Mostly yes. But Apache is so powerful I can do (and really did) a lot of
tricks - I can change LC_CTYPE with mod_env, I can map URLs to the
filesystem using mod_rewrite/ScriptAlias...
   FTP servers don't need to be that smart, but I'd like them to be more
configurable WRT filename encoding.
   But well, they are not, so the only thing to discuss is what to do with
ftplib and pyftpd. My not so humble opinion is - either use bytes instead
of strings or use latin-1 because it is the straightforward encoding that
preserves all 8 bits.

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
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

Re: [Python-Dev] __del__ and tp_dealloc in the IO lib

[Terry Reedy]

Giovanni Bajo wrote:



You are so very wrong, my son. CPython's implementation strategy
*will* evolve. Several groups are hard at work trying to make a faster
Python interpreter, and when they succeed, everyone, including you,
will want to use their version (or their version may simply *be* the
new CPython).


I'm basing my assumption on 19 years of history of CPython. Please, 
correct me if I'm wrong, but the only thing that changed is that the 
cyclic-GC was added so that loops are now collected, but nothing change 
with respect to cyclic collection. And everybody (including you, IIRC) 
has always agreed that it would be very very hard to eradicate reference 
counting from CPython and all the existing extensions; so hard that it 
is probably more convenient to start a different interpreter 
implementation.


Your history is true, but sometimes history changes faster than most 
expect. [As in the last 13 months of USA.]  A year ago, I might have 
agreed with you, but in the last 6 months, there has been more visible 
ferment in the area of dynamic language implementations than I remember 
seeing in the past decade.  When Guido says "CPython's implementation 
strategy *will* evolve" [emphasis his], I  believe him.  So this is just 
the wrong time to ask that it be frozen ;-).


While a strong argument can be made that the remaining 2.x versions 
should not be changed, they do not apply to 3.x.  New code and ported 
old code should use 'with' wherever quick closing needs to be 
guaranteed.  The 3.0 manual clearly states "An implementation is allowed 
to postpone garbage collection or omit it altogether "


OK, it also goes on to say "(Implementation note: the current 
implementation uses a reference-counting scheme with (optional) delayed 
detection of cyclically linked garbage,...)"  I think the first part 
should at least be amended to 'the current CPython implementation' or 
'the CPython implementation currently' or even better 'one current 
implementation (CPython)' and a warning added "But this may change" and 
"is not true of all implementaions" if that is not made clear otherwise.


Terry Jan Reedy






___
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

Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?

[rdmurray]

On Fri, 23 Jan 2009 at 21:23, "Martin v. L?wis" wrote:

Given that a Unix OS can't know what encoding a filename is in (*),
I can't see that one could practically implement a Unix FTP server
in any other way.


However, an ftp server is different. It might start up with an empty
folder, and receive *all* of its files through upload. Then it can
certainly know what encoding the file names have on disk. It *could*
also support operation on pre-existing files, e.g. by providing a
configuration directive telling the encoding of the file names, or
by ignoring all file names that are not encoded in UTF-8.


I don't see how starting with an empty directory helps.  The filename
comes from the client, and the FTP server can't know what the actual
encoding of that filename is.

--RDM___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Paul Moore]

2009/1/23 "Martin v. Löwis" :
>> Brett mentioned in his email that he wasn't ready to make a decision yet, I
>> think? I also think that the PEP could still use some modifications from 
>> people
>> who have more experience with the DVCSs.
>
> My question really was whether it is already ready for the wider
> audience up for discussion (and if so, what it is that should be
> discussed). It seems that it's not the case, so I just sit back and wait
> until its ready.

That's the impression I got - until Brett reaches the point of "Call
for rebuttals", he's not looking for input (other than factual
corrections of the capability and scenario sections). I'm not sure I'm
comfortable with sitting back and waiting to quite that extent (I'm
*already* biting my tongue over some of Brett's comments with which I
strongly disagree), but I'd rather not have the PEP dissolve in a
flamewar before Brett has a chance to study things better.

I appreciate the need for a considered, logical evaluation, but I'm
not sure keeping the lid on the impassioned arguments is going to make
them any less likely to explode when they finally do happen.

Paul.
___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Brett Cannon]

On Fri, Jan 23, 2009 at 13:39, Paul Moore  wrote:
> 2009/1/23 "Martin v. Löwis" :
>>> Brett mentioned in his email that he wasn't ready to make a decision yet, I
>>> think? I also think that the PEP could still use some modifications from 
>>> people
>>> who have more experience with the DVCSs.
>>
>> My question really was whether it is already ready for the wider
>> audience up for discussion (and if so, what it is that should be
>> discussed). It seems that it's not the case, so I just sit back and wait
>> until its ready.
>
> That's the impression I got - until Brett reaches the point of "Call
> for rebuttals", he's not looking for input (other than factual
> corrections of the capability and scenario sections).

That's right.

> I'm not sure I'm
> comfortable with sitting back and waiting to quite that extent (I'm
> *already* biting my tongue over some of Brett's comments with which I
> strongly disagree), but I'd rather not have the PEP dissolve in a
> flamewar before Brett has a chance to study things better.
>

It's going to dissolve anyway. I am just trying to keep it to a single
situation instead of having to go over it multiple times.

> I appreciate the need for a considered, logical evaluation, but I'm
> not sure keeping the lid on the impassioned arguments is going to make
> them any less likely to explode when they finally do happen.

I know it will explode. I am just trying to save myself the time of
not having to reply to the flood of emails that I know will come
before I have finished even thinking things through. It's like people
asking questions during a presentation that happen to be strongly
affected by the next slide; you can ask, but you might as well wait
until all the info is presented to start talking.

-Brett
___
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

Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?

[Martin v. Löwis]

> I don't see how starting with an empty directory helps.  The filename
> comes from the client, and the FTP server can't know what the actual
> encoding of that filename is.

Sure it can. If the client supports RFC 2640, it will send file names
in UTF-8. If the client does not support RFC 2640, the client must
restrict itself to 7-bit file names (i.e. ASCII). If the client violates
the protocol, the server must respond with error 501.

Regards,
Martin
___
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

Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?

[Roumen Petrov]

rdmur...@bitdance.com wrote:

On Fri, 23 Jan 2009 at 21:23, "Martin v. L�wis" wrote:

Given that a Unix OS can't know what encoding a filename is in (*),
I can't see that one could practically implement a Unix FTP server
in any other way.


However, an ftp server is different. It might start up with an empty
folder, and receive *all* of its files through upload. Then it can
certainly know what encoding the file names have on disk. It *could*
also support operation on pre-existing files, e.g. by providing a
configuration directive telling the encoding of the file names, or
by ignoring all file names that are not encoded in UTF-8.


I don't see how starting with an empty directory helps.  The filename
comes from the client, and the FTP server can't know what the actual
encoding of that filename is.


Exactly, only client can do filename conversion. May be ftplib could be 
extended to know encoding on filenames on local and remote system based 
on some user settings. May be ftplib could use UTF-8 or UCS-2/4 to store 
 internally filename but direct conversion is may be faster. It the 
last case filename is a byte sequence.


Roumen
___
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

Re: [Python-Dev] About SCons Re: progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80

[Roumen Petrov]

anatoly techtonik wrote:

On Thu, Jan 22, 2009 at 12:51 AM, Roumen Petrov
 wrote:

Against 2.3, rejected due to dependence on SCons.
Also appears to have been incomplete, needing more work.

No it was complete but use SCons. Most of changes changes in code you will
see again in 3871.



I would better use SCons for both unix and windows builds. In case of
windows for both compilers - mingw and microsoft ones. To port curses
extension to windows I need to know what gcc options mean, what are
the rules to write Makefiles and how to repeat these rules as well as
find options in visual studio interface. Not mentioning various
platform-specific defines and warning fixes.


Did you select one of existing curses library for windows ?

Roumen
___
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

Re: [Python-Dev] __del__ and tp_dealloc in the IO lib

[Guido van Rossum]

On Fri, Jan 23, 2009 at 12:52 PM, Terry Reedy  wrote:
> Giovanni Bajo wrote:
>>
>>> You are so very wrong, my son. CPython's implementation strategy
>>> *will* evolve. Several groups are hard at work trying to make a faster
>>> Python interpreter, and when they succeed, everyone, including you,
>>> will want to use their version (or their version may simply *be* the
>>> new CPython).
>>
>> I'm basing my assumption on 19 years of history of CPython. Please,
>> correct me if I'm wrong, but the only thing that changed is that the
>> cyclic-GC was added so that loops are now collected, but nothing change with
>> respect to cyclic collection. And everybody (including you, IIRC) has always
>> agreed that it would be very very hard to eradicate reference counting from
>> CPython and all the existing extensions; so hard that it is probably more
>> convenient to start a different interpreter implementation.
>
> Your history is true, but sometimes history changes faster than most expect.
> [As in the last 13 months of USA.]  A year ago, I might have agreed with
> you, but in the last 6 months, there has been more visible ferment in the
> area of dynamic language implementations than I remember seeing in the past
> decade.  When Guido says "CPython's implementation strategy *will* evolve"
> [emphasis his], I  believe him.  So this is just the wrong time to ask that
> it be frozen ;-).
>
> While a strong argument can be made that the remaining 2.x versions should
> not be changed, they do not apply to 3.x.  New code and ported old code
> should use 'with' wherever quick closing needs to be guaranteed.  The 3.0
> manual clearly states "An implementation is allowed to postpone garbage
> collection or omit it altogether "

I would hope the 2.x manual says the same, since that same assumption
has been around explicitly ever since JPython was first introduced.

I'm not sure we should exempt 2.x from these changes (though if only
3.x could be made twice as fast it would of course encourage people to
upgrade... :-). We've had many changes in the past affecting the
lifetime of local variables, usually due to changes in the way
tracebacks were managed.

> OK, it also goes on to say "(Implementation note: the current implementation
> uses a reference-counting scheme with (optional) delayed detection of
> cyclically linked garbage,...)"  I think the first part should at least be
> amended to 'the current CPython implementation' or 'the CPython
> implementation currently' or even better 'one current implementation
> (CPython)' and a warning added "But this may change" and "is not true of all
> implementaions" if that is not made clear otherwise.

True.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

[Python-Dev] distutils.mwerkscompiler and macpath deprecation

[Tarek Ziadé]

Hi,

for http://bugs.python.org/issue4863

If no one objects, I am going to remove the mwerkscompiler module from
distutils without any deprecation process, as Martin suggested
(since it is linked into ccompiler with "mac" for the os.name)

Now the question is, should I add a ticket to deprecate macpath.py as well ?

Regards
Tarek

-- 
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
___
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

Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now

[Roumen Petrov]

Luke Kenneth Casson Leighton wrote:
[SNIP]

python.exe (say, the official one) loads
python25.dll. Then, an import is made of a ming-wine extension, say
foo.pyd, which is linked with libpython2.5.dll, which then gets loaded.
Voila, you have two interpreters in memory, with different type objects,
memory heaps, and so on.


 ok, there's a solution for that - the gist of the solution is already
implemented in things like Apache Runtime and Apache2 (modules), and
is an extremely common standard technique implemented in OS kernels.
the "old school" name for it is "vector tables".

[SNIP] Did you think that this will escape python MSVC from "Assembly 
hell" ?


Roumen
___
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

Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now

[Roumen Petrov]

[SNIP]

No, Python 2.5 is linked with msvcr71.dll.

 ehn? i don't see that anywhere in any PC/* files - i do see that
there's a dependency on .NET SDK 1.1 which uses msvcr71.dll


Take a look at PCbuild/pythoncore.vcproj. It says

Version="7.10"

This is how you know VS 2003 was used to build Python 2.5, which
in turn links in msvcr71.dll.


Luke, the python MSVC build assume equivalence between MSVC compiler and 
 runtime, i.e. if compiler is version X the runtime is version Y.
This is not try for GCC(mingw) build. This compiler is more flexible and 
allow build against different runtimes. But you know this - I already 
comment issue870382 in the patch.




Regards,
Martin

___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Terry Reedy]

Brett Cannon wrote:

On Fri, Jan 23, 2009 at 13:39, Paul Moore  wrote:


I'm not sure I'm
comfortable with sitting back and waiting to quite that extent (I'm
*already* biting my tongue over some of Brett's comments with which I
strongly disagree), but I'd rather not have the PEP dissolve in a
flamewar before Brett has a chance to study things better.



It's going to dissolve anyway. I am just trying to keep it to a single
situation instead of having to go over it multiple times.


I have two suggestions:

1. Conduct the discussion on python-ideas rather than python-dev so as 
to not overwhelm the day-to-day discussions and also to provide a bit of 
psychological distance.


2. Have several focused threads.  Some examples:

Given three experimental setups
a. Experience with bzr
b. Experience with hg
c. Experience with git
later
d. Comparisons based on real experience

Your different comments might best be separately discussed.
"In the PEP, I said 'blah, blah'. Comments?"

Terry

___
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

Re: [Python-Dev] __del__ and tp_dealloc in the IO lib

[Terry Reedy]

Guido van Rossum wrote:

On Fri, Jan 23, 2009 at 12:52 PM, Terry Reedy  wrote:



While a strong argument can be made that the remaining 2.x versions should
not be changed, they do not apply to 3.x.  New code and ported old code
should use 'with' wherever quick closing needs to be guaranteed.  The 3.0
manual clearly states "An implementation is allowed to postpone garbage
collection or omit it altogether "


I would hope the 2.x manual says the same, since that same assumption
has been around explicitly ever since JPython was first introduced.


Yes.  It was changed a bit when gc was added.


I'm not sure we should exempt 2.x from these changes (though if only
3.x could be made twice as fast it would of course encourage people to
upgrade... :-).


;-)
If the issue became real, one could ask 2.x users which they prefer, 
compatability or speed.  I have no opinion since my concern is with 3.x.



OK, it also goes on to say "(Implementation note: the current implementation
uses a reference-counting scheme with (optional) delayed detection of
cyclically linked garbage,...)"  I think the first part should at least be
amended to 'the current CPython implementation' or 'the CPython
implementation currently' or even better 'one current implementation
(CPython)' and a warning added "But this may change" and "is not true of all
implementaions" if that is not made clear otherwise.


True.


http://bugs.python.org/issue5039

tjr


___
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

Re: [Python-Dev] PEP 374 (DVCS) now in reST

[Nick Coghlan]

Brett Cannon wrote:
> On Fri, Jan 23, 2009 at 12:11, Steven Bethard  
> wrote:
>> On Fri, Jan 23, 2009 at 12:06 PM, "Martin v. Löwis"  
>> wrote:
 import random
 print(random.choice('svn', 'bzr', 'hg', 'git'))
>>> Nice! So it's bzr, as my machine just told me (after adding
>>> the square brackets).
>> Wow, that decision was a lot easier than I thought it would be. ;-)
> 
> But my machine just told me svn, which is even easier as that means we
> don't need to change anything. =)

Mine briefly flirted with git, but quickly changed its mind. It *is* a
Kubuntu machine though, so it's probably biased :)

Cheers,
Nick.

>>> import random
>>> random.choice(['svn', 'bzr', 'hg', 'git'])
'git'
>>> random.choice(['svn', 'bzr', 'hg', 'git'])
'bzr'
>>> random.choice(['svn', 'bzr', 'hg', 'git'])
'bzr'
>>> random.choice(['svn', 'bzr', 'hg', 'git'])
'bzr'

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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