Re: [Python-Dev] Closing outdated Mac issues

[Ned Deily]

In article 
<2d75d7660902151517p22440361u76f686dc2f0e1...@mail.gmail.com>,
 "Daniel (ajax) Diniz"  wrote:
> Brett Cannon wrote:
> > As of Python 2.6 everything Mac-specific is deprecated and in 3.0 they
> > are gone (you can read PEP 3108 for the details or just note that the
> > Mac/Modules directory is gone in 3.0). They will still be around in 2.7,
> > though, as these are Py3K deprecations.
> OK, I've now read PEPs 3108 and 11, but still would like some ruling
> about RFEs in these stagnated Mac modules. Maybe PEP 4 could include a
> note about RFEs in deprecated modules?
> > Not sure what has been left in
> > the Mac directory, but I think it is just random scripts (I never use
> > the Mac-specific stuff so I don't know how useful some of them are to
> > keep).

Other than Mac/Modules, the rest of the Mac/ directory is mainly stuff 
used for building or going into the OS X installer images, including 
things like IDLE.app.  These are used in 2.x and in 3.x.
 
> There are 40 C files, two headers and 69 python files in /Mac in
> trunk. The 2.6 (and 2.5.x) docs say development has stopped and that
> they'd be replaced in 2.5. So ISTM closing RFEs for these modules
> would be an improvement.
> 
> > Honestly, fixing them is fine but since the modules are deprecated but
> > still in existence in 2.x, but they are definitely nothing above a
> > normal priority issue.
> OK, I'll let the bug reports open. What about RFEs?

I think the reasonable thing to do is close them as "not to be 
fixed/implemented".  At this point, the chances that someone would fix 
them are pretty slim and, in many cases, I'm sure the module is either 
obsolete because other, and better supported, solutions are now 
available, like PyObjC or appscript.  If people feel strongly about an 
issue, they can always ask to re-open it.

Taking a quick look at your list, the only ones that may be worth 
looking at are the plistlib ones since it lives on in 3.x.  I think all 
the rest are deprecated and gone in 3.x.

-- 
 Ned Deily,
 n...@acm.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

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

[Ned Deily]

In article <6fc960b6-7723-4887-9342-fac4d0c93...@mac.com>,
 Ronald Oussoren  wrote:
> I'll be at Pycon and part of post-pycon sprint days (I'm flying back  
> on april 1st).  I had already planned to try to get a mac-related  
> sprint going at pycon, I've added work on this on the list of possible  
> topics.

Sounds like there will be no lack of things to talk about at Pycon!

Thanks to everyone for their input on this.  And congratulations on 
getting 3.0.1 - with OS X support - out there.

-- 
 Ned Deily,
 n...@acm.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

Re: [Python-Dev] RELEASED Python 3.0.1

[Ned Deily]

In article 
,
 Benjamin Kaplan  wrote:
> Any chance of getting a Mac installer for this one?

BTW, I see the a link to the OS X installer has now been added to the 
3.0.1 release page:
   

It would be great if someone could add OS X links for the 3.0.1 and 
2.6.1 to the main download page, too:
   

-- 
 Ned Deily,
 n...@acm.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

Re: [Python-Dev] No 2.x->3.x porting documentation?

[Benjamin Peterson]

On Sun, Feb 15, 2009 at 8:59 PM,   wrote:
> If neither of these changes could be handled by 2to3 I think it would have
> been useful to at least document the changes (in whatsnew/3.0.rst?) and
> maybe offer humans some workaround ideas.  If there is a wiki page
> collecting porting wisdom it should be referenced.  If I'm missing something
> fundamental about how people are expected to approach porting 2.x code to
> 3.x, please let me know.

All your points are valid. See http://wiki.python.org/moin/PortingToPy3k

Please contribute if you can!



-- 
Regards,
Benjamin
___
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] No 2.x->3.x porting documentation?

[skip]

I apologize if this has been discussed here or elsewhere already.  I'm
offline as I write this so my only source of guidance is what I find in my
Subversion checkouts.

I'm making a naive stab at converting nose to Python3 so I can hopefully run
the lockfile test cases under Python 3.  (Again, I'm offline and have no
idea at this point if it's been done already.)  I ran 2to3 then tried
installing.  I got an immediate error about the compiler.consts module being
missing.  (All nose does is import CO_GENERATOR from compiler.consts.)  I
found that in the inspect module.  Then it complained about ClassType being
missing from the types module.  I found no mention of changes to the types
module in Misc/NEWS or Doc/whatsnew/3.0.rst.  I didn't find anything which
looked like a "porting" document.

If neither of these changes could be handled by 2to3 I think it would have
been useful to at least document the changes (in whatsnew/3.0.rst?) and
maybe offer humans some workaround ideas.  If there is a wiki page
collecting porting wisdom it should be referenced.  If I'm missing something
fundamental about how people are expected to approach porting 2.x code to
3.x, please let me know.

Thanks,

Skip

___
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] OS X Installer for 3.0.1 and supported versions

[Ned Deily]

In article 
,
 Alex Martelli  wrote:
> On Sat, Feb 14, 2009 at 3:22 AM, Ned Deily  wrote:
>...
> > have done complete and thorough testing.  (In particular, I have no
> > access to a G5 for 64-bit PPC testing.)
> I have a PowerMac G5 at home and I'll be glad to run tests if it
> helps.

Thanks, Alex.  I'll contact you off-list about this.

-- 
 Ned Deily,
 n...@acm.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

Re: [Python-Dev] draft 3.1 release schedule

[Benjamin Peterson]

On Sun, Feb 15, 2009 at 10:59 AM, Guido van Rossum  wrote:
> On Sat, Feb 14, 2009 at 12:29 PM, Benjamin Peterson  
> wrote:
>> 3.1a1 March 7 (Saturday)
>> 3.1a2 April 11 (Saturday)
>> 3.1b1 May 2 (Saturday)
>> 3.1b2 May 23 (Saturday)
>> 3.1rc1 June 13 (Saturday)
>> 3.1rc2 June 27 (Saturday)
>
> And final release on...?

Oops! Forgot about that one. :) July 4th.

>> I'm interested in your feedback with regards to the amount of time in
>> beta and RC phase. Do you think we need that much time? Otherwise, we
>> could move the final release back sometime in mid June.
>
> It's a bit hard to compare this to other release schedules because
> it's coming much sooner after 3.0. I would guess this means that not
> as much has changed, and so the schedule could conceivably more
> compressed. If you want to take beta seriously as a time of
> consolidation where no new features should be added and no API changes
> should take place, you might consider dropping one beta, since in
> practice it is often hard to keep developers from wanting to change
> stuff anyways.

Something like this?

3.1a1 March 7
3.1a2 April 4
3.1b1 May 2
3.1rc1 May 30
3.1rc2 June 13
3.1 Final June 27

That sounds reasonable. I will try to enforce a fairly strict
stability policy during the beta and RCs.

> You might also want to collect a list of serious changes that you want
> in this release; I know I/O in C is on the list (and without it I
> wouldn't consider it worth releasing) but there may be others. The
> developers of such features ought to be on board with delivering their
> code before the first beta.

I've started a list on the release PEP [1].

[1] http://www.python.org/dev/peps/pep-0375/



--
Regards,
Benjamin
___
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] Closing outdated Mac issues

[Daniel (ajax) Diniz]

Looks like the MDS ate the copy sent to the list, here's it again:

Brett Cannon wrote:
> As of Python 2.6 everything Mac-specific is deprecated and in 3.0 they
> are gone (you can read PEP 3108 for the details or just note that the
> Mac/Modules directory is gone in 3.0). They will still be around in 2.7,
> though, as these are Py3K deprecations.

OK, I've now read PEPs 3108 and 11, but still would like some ruling
about RFEs in these stagnated Mac modules. Maybe PEP 4 could include a
note about RFEs in deprecated modules?

> Not sure what has been left in
> the Mac directory, but I think it is just random scripts (I never use
> the Mac-specific stuff so I don't know how useful some of them are to
> keep).

There are 40 C files, two headers and 69 python files in /Mac in
trunk. The 2.6 (and 2.5.x) docs say development has stopped and that
they'd be replaced in 2.5. So ISTM closing RFEs for these modules
would be an improvement.

> Honestly, fixing them is fine but since the modules are deprecated but
> still in existence in 2.x, but they are definitely nothing above a
> normal priority issue.

OK, I'll let the bug reports open. What about RFEs?

Daniel
___
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] .Idle.py init file

[Daniel (ajax) Diniz]

Mitchell,

I can't find the string ".Idle.py" in trunk. If you haven't already,
please open a documentation issue for this one. I don't see any
obvious downside to this behavior and people might be relying on it by
now.

Thanks for  reporting these IDLE issues!

Daniel
___
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] Closing outdated Mac issues

[Brett Cannon]

On Sun, Feb 15, 2009 at 12:13, Daniel (ajax) Diniz  wrote:

> Hi,
>
> In the discussion of a feature request for MacPython[1], the OP (hhas)
> said:
>
>As of Python 2.6/3.0, all Mac-specific modules are deprecated/eliminated
>from the standard library and there are no longer any plans to submit
>appscript for possible inclusion. This issue should be rejected and
>closed.
>
> If that is the current state of Mac modules, there are no less than 17
> issues* that should be closed, 4 bug reports** that might be kept open
> and 4 mixed-cases*** that might be obsolete/irrelevant.
>
> Besides amounting to 1% of open issues, these can divert efforts to
> bogus issues: I've submitted a patch for one of the mixed-cases (bug +
> feature request), but now don't think it was worth it.
>
> So, if someone could reassure / clarify the rules for closing these in
> general and/or take a quick look at specific issues, that would be a
> great help.
>

As of Python 2.6 everything Mac-specific is deprecated and in 3.0 they are
gone (you can read PEP 3108 for the details or just note that the
Mac/Modules directory is gone in 3.0). They will still be around in 2.7,
though, as these are Py3K deprecations. Not sure what has been left in the
Mac directory, but I think it is just random scripts (I never use the
Mac-specific stuff so I don't know how useful some of them are to keep).

Honestly, fixing them is fine but since the modules are deprecated but still
in existence in 2.x, but they are definitely nothing above a normal priority
issue.

-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

[Python-Dev] Closing outdated Mac issues

[Daniel (ajax) Diniz]

Hi,

In the discussion of a feature request for MacPython[1], the OP (hhas) said:

As of Python 2.6/3.0, all Mac-specific modules are deprecated/eliminated
from the standard library and there are no longer any plans to submit
appscript for possible inclusion. This issue should be rejected and
closed.

If that is the current state of Mac modules, there are no less than 17
issues* that should be closed, 4 bug reports** that might be kept open
and 4 mixed-cases*** that might be obsolete/irrelevant.

Besides amounting to 1% of open issues, these can divert efforts to
bogus issues: I've submitted a patch for one of the mixed-cases (bug +
feature request), but now don't think it was worth it.

So, if someone could reassure / clarify the rules for closing these in
general and/or take a quick look at specific issues, that would be a
great help.

Issue lists below.

Regards,
Daniel

[1] http://bugs.python.org/issue916013

* Feature requests and implementation polishing issues:

http://bugs.python.org/issue706585 Expose FinderInfo in FSCatalogInfo

http://bugs.python.org/issue706592 Carbon.File.FSSpec should accept
non-existing pathnames

http://bugs.python.org/issue776533 Carbon.Snd module SPB constructor shadowed

http://bugs.python.org/issue779285 Carbon Event ReceiveNextEvent

http://bugs.python.org/issue806149 aetools.TalkTo methods can be obscured

http://bugs.python.org/issue822005 Carbon.CarbonEvt.ReceiveNextEvent args wrong

http://bugs.python.org/issue852150 Can't send Apple Events without
WindowServer connection

http://bugs.python.org/issue853656 Carbon.CF.CFURLRef should be easier to create

http://bugs.python.org/issue869649 Quicktime missing funcitonality

http://bugs.python.org/issue878560 Add a console window for Carbon
MacPython applets

http://bugs.python.org/issue881824 Add ResolveFinderAliases to macostools module

http://bugs.python.org/issue1089399 Carbon.Res misses GetIndString

http://bugs.python.org/issue1089624
Carbon.File.FSCatalogInfo.createDate implementation

http://bugs.python.org/issue1090958 _AEModule.c patch

http://bugs.python.org/issue1113328 OSATerminology still semi-broken

http://bugs.python.org/issue1169679 modules missing from list of Carbon modules

http://bugs.python.org/issue1254695 QuickTime API needs corrected object types


** Bug reports, might be worth fixing in 2.6:

http://bugs.python.org/issue1004810 Carbon.File fails if server vol is
mounted after launch

http://bugs.python.org/issue1123727 gensuitemodule.processfile fails

http://bugs.python.org/issue1700507 Carbon.Scrap.PutScrapFlavor

http://bugs.python.org/issue1155 Carbon.CF memory management problem


** Probably out of  date, irrelevant or both:

http://bugs.python.org/issue779153 bgen requires Universal Headers,
not OS X dev headers

http://bugs.python.org/issue602291 Bgen should learn about booleans

http://bugs.python.org/issue775321 plistlib error handling

http://bugs.python.org/issue985064 plistlib crashes too easily on bad files
___
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] smtplib violates SMTP spec

[Aahz]

On Sun, Feb 15, 2009, Felix Schwarz wrote:
>
> I would like to get attention to issue 4142 [1] which was filed several 
> months ago. This is about a clear bug in smtplib's SMTP implementation 
> which is probably present since (at least) Python 1.5.
>
> When re-using an smtplib.SMTP instance for a second connection, smtplib 
> does not send another HELO/EHLO which is a clear violation of the SMTP 
> specification.
>
> I built a small patch (changes only 2 lines) but I'm unable to write a 
> unit test for this easily because:
>   * Python's smtpd does not check if HELO/EHLO was received before MAIL FROM
>   * Therefore any extension of test_smtplib would need some patches to check
> this also.

If you want to increase the chance of your patch getting into 2.7/3.1,
please provide a patch against smtpd in addition to your smtplib patch.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.
___
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] smtplib violates SMTP spec

[Felix Schwarz]

Hi,

I would like to get attention to issue 4142 [1] which was filed several months 
ago. This is about a clear bug in smtplib's SMTP implementation which is 
probably present since (at least) Python 1.5.


When re-using an smtplib.SMTP instance for a second connection, smtplib does 
not send another HELO/EHLO which is a clear violation of the SMTP specification.


I built a small patch (changes only 2 lines) but I'm unable to write a unit 
test for this easily because:

  * Python's smtpd does not check if HELO/EHLO was received before MAIL FROM
  * Therefore any extension of test_smtplib would need some patches to check
this also.

However, the patch is very small so it is very easy to test this manually. 
Just connect to a real world smtp (Exim is best because it is quite strict 
when it comes to SMTP verbs).


fs

[1] http://bugs.python.org/issue4142

___
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] draft 3.1 release schedule

[Guido van Rossum]

On Sat, Feb 14, 2009 at 12:29 PM, Benjamin Peterson  wrote:
> Here's a very tentative 3.1 release schedule.

Thanks! Glad you're taking your new role of release manager seriously
and are starting to plan ahead.

> 3.1a1 March 7 (Saturday)
> 3.1a2 April 11 (Saturday)
> 3.1b1 May 2 (Saturday)
> 3.1b2 May 23 (Saturday)
> 3.1rc1 June 13 (Saturday)
> 3.1rc2 June 27 (Saturday)

And final release on...?

> I'm interested in your feedback with regards to the amount of time in
> beta and RC phase. Do you think we need that much time? Otherwise, we
> could move the final release back sometime in mid June.

It's a bit hard to compare this to other release schedules because
it's coming much sooner after 3.0. I would guess this means that not
as much has changed, and so the schedule could conceivably more
compressed. If you want to take beta seriously as a time of
consolidation where no new features should be added and no API changes
should take place, you might consider dropping one beta, since in
practice it is often hard to keep developers from wanting to change
stuff anyways.

You might also want to collect a list of serious changes that you want
in this release; I know I/O in C is on the list (and without it I
wouldn't consider it worth releasing) but there may be others. The
developers of such features ought to be on board with delivering their
code before the first beta.

-- 
--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] OS X Installer for 3.0.1 and supported versions

[Ronald Oussoren]

On 14 Feb, 2009, at 20:15, Martin v. Löwis wrote:


Ronald Oussoren wrote:


On 14 Feb, 2009, at 19:04, Martin v. Löwis wrote:


A single installer could support both 32-bit on 10.4 and 64-bit on
10.5, but I don't think that's very useful because there are  
changes
in the low-level unix API's that could result in different  
behaviour
of a 32-bit and 64-bit script on the same system. In general 10.5  
has

much saner Unix API's than earlier releases.


I don't get that. Why would the scripts behave differently on 10.5
depending on whether the Python interpreter is 32-bit or 64-bit?
Surely, the Unix API does the same thing, whether invoked from 32- 
bit

code, or 64-bit code, no?


I should have been more clear: the unix API for code that runs on
10.4 is slightly different than that for code that runs on 10.5+,  
Apple

basiclly fixed a number of UNIX API-compliance issues in 10.5.


So how come? Are you really saying that 10.5 somehow knows whether the
code might also run on 10.4, and if so, deliberately behaves
differently?


Yes. OSX supports a variant of symbol versioning. The dynamic linker  
can see for which system a binary was compiler build and links the  
right version of a symbol at runtime.


There's the comment in the header files that defines the macro's used  
for symbol versioning:


/*
 * The __DARWIN_ALIAS macros are used to do symbol renaming; they allow
 * legacy code to use the old symbol, thus maintiang binary  
compatability
 * while new code can use a standards compliant version of the same  
function.

 *
 * __DARWIN_ALIAS is used by itself if the function signature has not
 * changed, it is used along with a #ifdef check for __DARWIN_UNIX03
 * if the signature has changed.  Because the __LP64__ enviroment
 * only supports UNIX03 sementics it causes __DARWIN_UNIX03 to be
 * defined, but causes __DARWIN_ALIAS to do no symbol mangling.
 *
 * As a special case, when XCode is used to target a specific version  
of the
 * OS, the manifest constant  
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
 * will be defined by the compiler, with the digits representing  
major version
 * time 100 + minor version times 10 (e.g. 10.5 := 1050).  If we are  
targetting

 * pre-10.5, and it is the default compilation environment, revert the
 * compilation environment to pre-__DARWIN_UNIX03.
 */

Simply put: when a binary is compiled to run on 32-bit 10.4 or earlier  
it will be linked to pre-Unix03 symbols, otherwise it will be linked  
with the Unix'03 compliant symbols/APIs. Some API's just behave  
differently, others have a different signature as well.





So that a Python interpreter compiled for 10.4+ would behave  
differently

on a specific 10.5 installation than a Python interpreter compiled for
10.5+, on the very same system?

If so, I'm -1 on providing two sets of binaries for the same Python
version (one in 10.4+ mode and one in 10.5+ mode). Otherwise, this
sounds like a good source of confusion: "are you using Python 3.1
as compiled for 10.4 or 3.1 as compiled for 10.5?" - "well, how
do I tell?"


It should be easy to provide that information.

And anyway, we already have confusion about python builds anyway: the  
python.org, macports and fink builds of python are slightly different  
and some issues seem to crop up with some of the builds more often  
than with others. That is, I sometimes see questions on the pythonmac- 
sig from macports and fink users about issues that I've never run into  
with the python.org build.



Is this Apple's DLL hell?


Not quite a hell, but still inconvenient.  I guess it is time to start  
digging to check which API's have a different definition in UNIX03 to  
check if those could affect the behaviour of the Python interpreter.   
I know the value of "GETPGRP_HAVE_ARG" is affected by this, but Python  
scripts are shielded from that because the interface of the posix  
module is the same regardless of the value of this macro.


We'd still end up with a build-hell when we'd want to provide a 4-way  
universal build that can run on 10.4 as well, because 64-bit code is  
always in UNIX03 mode, while 32-bit code that needs to run on 10.4   
cannot be.  I have some idea's about how to work around that issue,  
but need time to investigate the viability of those ideas.


Ronald

smime.p7s
Description: S/MIME cryptographic 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