> 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 P
> 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
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
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 p
> 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
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
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 communi
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.
>
> O
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 closin
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
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
> 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
> re
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 re
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 f
-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 DVC
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 applicati
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
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
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
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
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
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 fo
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
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 f
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
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
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...@pa
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 sav
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 iss
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: Janua
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-kn
> 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/
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
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, th
> 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 have
> 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
> 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
cer
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
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
n
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 receiv
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
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.
>>
> 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, th
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 wi
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 be
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,
>>>
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 ma
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,
[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 bu
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
flam
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
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 s
52 matches
Mail list logo
