[issue1877] unhelpful error when calling "python "

[Nick Coghlan]

Nick Coghlan added the comment:

We don't want to restore Python 2.5 behaviour - directories containing a
__main__.py file are meant to be executable in 2.6. With your proposed
change test_cmd_line_script will fail its directory execution tests
(since those rely on the default importer to find the code for __main__).

Georg is rightly complaining about the way that the implementation
details leak through in the error message when __main__ isn't found. It
makes perfect sense to me, but anyone that isn't intimately familiar
with the import system is going to be left scratching their heads and
wondering what is going on.

I'm currently pondering an approach that involves trapping the
ImportError in _run_module_as_main and displaying different error
messages based on whether or not the module being looked for is called
__main__, and whether or not sys.argv[0] is a directory.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1742669] "%d" format handling for long values

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

I am of the opposite side:
%d should accept floats and anything that can be converted to an integer.
It is for printing objects with a decimal format.
(likewise %s is for printing objects that can be converted to a string)

--
nosy: +amaury.forgeotdarc

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2160] Document PyImport_GetImporter

[Christian Heimes]

Christian Heimes added the comment:

Thanks :)

--
assignee:  -> georg.brandl
keywords: +patch
nosy: +georg.brandl, tiran
priority:  -> low

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1877] unhelpful error when calling "python "

[Nick Coghlan]

Nick Coghlan added the comment:

I've checked in friendlier error messages as r60955

Examples (paths somewhat redacted):

$ ./python bob
./python: can't open file 'bob': [Errno 2] No such file or directory
$ ./python .
/devel/python/python: can't find '__main__.py' in '.'
$ ./python Lib
/devel/python/python: can't find '__main__.py' in 'Lib'
$ ./python -m bob
/devel/python/python: No module named bob
$ ./python -m sys
/devel/python/python: No code object available for sys
$ ./python -m __main__
/devel/python/python: No code object available for __main__

--
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1742669] "%d" format handling for long values

[Facundo Batista]

Facundo Batista added the comment:

Paul, %d will accept large floats, I need to review Gabriel's patch;
your proposition will break too much code.

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2161] STORE_LOCAL byte code is not documented

[Peter Tröger]

New submission from Peter Tröger:

The byte code STORE_LOCAL is referenced in the description of
STORE_NAME, but has no own entry in the list. See here:

http://docs.python.org/lib/bytecodes.html

--
components: Documentation
messages: 62685
nosy: troeger
severity: minor
status: open
title: STORE_LOCAL byte code is not documented
type: feature request
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2162] unittest.findTestCases undocumented

[Paul Winkler]

Changes by Paul Winkler:


--
components: Documentation
nosy: slinkp
severity: normal
status: open
title: unittest.findTestCases undocumented
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2162] unittest.findTestCases undocumented

[Paul Winkler]

New submission from Paul Winkler:

I cannot find anything about findTestCases on any of the library doc
pages, certainly not at http://docs.python.org/lib/unittest-contents.html
where I'd expect it to be.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1858] Make .pypirc handle multiple servers

[Tarek Ziadé]

Changes by Tarek Ziadé:


Added file: http://bugs.python.org/file9489/distutils.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1858] Make .pypirc handle multiple servers

[Tarek Ziadé]

Tarek Ziadé added the comment:

please could you remove the deprecated patch.diff ? thanks :)

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2162] unittest.findTestCases undocumented

[Virgil Dupras]

Virgil Dupras added the comment:

findTestCases is an obsolete function. From the code:

# Expose obsolete functions for backwards compatibility
__all__.extend(['getTestCaseNames', 'makeSuite', 'findTestCases'])

--
nosy: +vdupras

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue896199] Some Carbon modules missing

[Jeroen Ruigrok van der Werven]

Jeroen Ruigrok van der Werven added the comment:

Is this not solved with the new documentation interface? It groups all 
Carbon modules under a collapsable tree element.

See http://docs.python.org/dev/modindex.html under Carbon

--
nosy: +asmodai, georg.brandl


Tracker <[EMAIL PROTECTED]>


___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1877] unhelpful error when calling "python "

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Nick,

I understand the __main__.py issue now, but I still don't like your 
approach.  Allowing RunMainFromImporter to call exit and never return 
does not feel right. (A minor problem is that objects on the C stack do 
not get deleted.)  Without a check for Py_None return, the comment 
"argv0 is usable as an import source" is misleading.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2138] Factorial

[ajaksu]

ajaksu added the comment:

Would it be implemented in C? How about using Luschny's Prime Swing
(http://www.luschny.de/math/factorial/FastFactorialFunctions.htm and
http://www.luschny.de/math/factorial/Benchmark.html )?

--
nosy: +ajaksu2

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue896199] Some Carbon modules missing

[Georg Brandl]

Georg Brandl added the comment:

Still, I don't see File, Files or Folders under that heading.


Tracker <[EMAIL PROTECTED]>


___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2163] test_socket is flakey

[Guido van Rossum]

New submission from Guido van Rossum:

I find that test_socket fails regularly (but not always) when run via
"regrtest.py -uall". The message is always "socket is not connected" but
it's unclear from which test it comes -- all I know is that it comes
from tearDown() on line 123.

(This may be a problem with 2.6 as well -- or not.)

--
components: Tests
keywords: easy
messages: 62693
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: test_socket is flakey
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1877] unhelpful error when calling "python "

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

I think a more elegant solution will be possible if issue2135 patch is 
accepted.  I suggest to reopen this issue for Py3k pending resolution of 
issue2135.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue839159] iterators broken for weak dicts

[A.M. Kuchling]

Changes by A.M. Kuchling:


--
title: interators broken for weak dicts -> iterators broken for weak dicts


Tracker <[EMAIL PROTECTED]>


___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2164] dl broken on non-ILP32 platforms

[Bill Nottingham]

New submission from Bill Nottingham:

SystemError: module dl requires sizeof(int) == sizeof(long) == sizeof(char*)

That's just unspeakably lame. I realize this is longstanding, and it's
even documented, but just... FAIL.

--
components: Library (Lib)
messages: 62695
nosy: notting
severity: normal
status: open
title: dl broken on non-ILP32 platforms
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2135] Restructure import.c into PEP 302 importer objects

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

The patch breaks test_import on Mac OS 10.4:

$ ./python.exe -E -tt -bb ./Lib/test/regrtest.py test_import
test_import
test test_import failed -- Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 1199, in 
main()
  File "./Lib/test/regrtest.py", line 405, in main
huntrleaks)
  File "./Lib/test/regrtest.py", line 562, in runtest
huntrleaks, debug)
  File "./Lib/test/regrtest.py", line 614, in runtest_inner
print("test", test, "failed --", msg)
  File "/Users/sasha/Work/python-svn/py3k/Lib/io.py", line 1247, in 
write
b = encoder.encode(s)
  File "/Users/sasha/Work/python-svn/py3k/Lib/encodings/ascii.py", line 
22, in encode
return codecs.ascii_encode(input, self.errors)[0]
UnicodeEncodeError: 'ascii' codec can't encode characters in position 
211-214: ordinal not in range(128)

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2164] dl broken on non-ILP32 platforms

[Bill Nottingham]

Bill Nottingham added the comment:

Moreover, eliding the check and subsequent error from the code yields a
module that appears to work in (very) brief testing on x86_64.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2135] Restructure import.c into PEP 302 importer objects

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

I've noticed that the proposed patch adds const qualifier to many C-API 
functions' arguments.  While at the first glance these changes are 
reasonable, they add clutter to the already massive patch.

I would recommend to separate const qualifier changes into a separate 
patch that can be reviewed separately from the substantive changes.

I promise, I will make substantive comments soon. :-)

--
nosy: +belopolsky

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2164] dl broken on non-ILP32 platforms

[Bill Nottingham]

Bill Nottingham added the comment:

sizeof(long) != sizeof(void *) isn't the epic fail here. It's the
complaint about sizeof(int) != sizeof(long).

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2164] dl broken on non-ILP32 platforms

[Martin v. Löwis]

Martin v. Löwis added the comment:

> sizeof(long) != sizeof(void *) isn't the epic fail here. It's the
> complaint about sizeof(int) != sizeof(long).

Same story.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2164] dl broken on non-ILP32 platforms

[Bill Nottingham]

Bill Nottingham added the comment:

If it's not possible to implement at all, why does it work without the
test?  What specific cases do you think will fail?

Heck, if you don't think it's functional on 90% of hardware sold these
days, just remove it, it makes python look less silly. (Portability is
hard, let's punt.)

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2164] dl broken on non-ILP32 platforms

[Martin v. Löwis]

Martin v. Löwis added the comment:

The limitation is genuine; it's not possible to implement dl_call
correctly if sizeof(long) != sizeof(void*), say. Otherwise, it would
have been fixed long ago. Use ctypes instead, if that is supported for
your hardware. (More generally, it's not possible to implement this at
all in portable C, that's why ctypes uses assembler code. That dl works
on most "pure" 32-bit systems is by sheer luck)

--
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2054] add ftp-tls support to ftplib - RFC 4217

[Bill Janssen]

Bill Janssen added the comment:

This is a straightforward implementation of client-side use of SSL, but
it's missing a test case for evaluation.  It should include a patch to
test_ftplib to test it.

Another thing to look at is what the useful arguments are to pass in for
TLS usage over FTP.  If, for example, the client needs to validate the
server's certificate or identity, provision should be made for a file of
cacerts to be passed to the FTP_TLS instance.  Passing in a keyfile and
certfile is usually only necessary when the client uses them to identify
itself to the server.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2135] Restructure import.c into PEP 302 importer objects

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

First, let me state that I like the idea of a uniform approach to 
importing, but given the complexity of the task, Brett's approach (which 
I understand as implementing the builtin importer classes in Python) 
would make sense (as long as he can solve the chicken and egg problem).

This said, here is my first question:

Is there a reason why new importer classes are not subclassable while 
zipimporter is?

>>> class x(imp.BuiltinImporter):pass
... 
Traceback (most recent call last):
  File "", line 1, in 
TypeError: type 'imp.BuiltinImporter' is not an acceptable base type

>>> class x(imp.DirectoryImporter): pass
... 
Traceback (most recent call last):
  File "", line 1, in 

>>> class x(zipimport.zipimporter): pass
... 


Users might want to overload find_module while reusing load_module from 
a built-in importer class.

In fact, I see a great deal of code duplication between the new importer 
classes that can be reduced by deriving from a common base class.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2135] Restructure import.c into PEP 302 importer objects

[Brett Cannon]

Brett Cannon added the comment:

Sorry I have not commented on this sooner; been swamped.

First, the error Alexander is seeing is probably caused by a source file
that has an encoding other than ASCII (which is fine as the default
encoding in Python 3.0 is UTF-8). But chances are the file has an
encoding marker at the top and that is not being picked up by Douglas'
code. Look at PyTokenizer_FindEncoding() for a way to find out the encoding.

Second, I am the wrong person to be reviewing this as I have something
under development that competes with this. =) I am trying to get my pure
Python implementation bootstrapped into Python 3.0 to completely replace
the C code. But I don't know if I will pull this off in time so this
work could still be useful. But if I have to choose time between this
patch and my stuff, I am going to be biased. =)

--
assignee: brett.cannon -> 

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2164] dl broken on non-ILP32 platforms

[Martin v. Löwis]

Martin v. Löwis added the comment:

It fails if the function being called has parameters which are not
sizeof(long), and the platform has a calling convention where such
parameters are passed on the stack, and consume a size different from
sizeof(long) on the stack.

I disagree that it won't run on 90% of the hardware sold today - you
just have to operate that hardware properly to make it work. In any
case, removal of the dl module in favor of ctypes seems reasonable.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2138] Factorial

[Anders Valind]

Anders Valind added the comment:

IMHO, The best place to put functions such as xgcd, factorial, etc,
would be a new imath module, an integer equivalent of cmath.

Not only would it keep the standard math module clean, it would also
make clear that these functions are for integers only.

--
nosy: +avalind

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1631171] implement warnings module in C

[Brett Cannon]

Brett Cannon added the comment:

Patch that has been brought up-to-date with r60968. No new work, though.

Added file: http://bugs.python.org/file9490/c_warnings.diff

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1631171] implement warnings module in C

[Brett Cannon]

Changes by Brett Cannon:


Removed file: http://bugs.python.org/file7708/c-warnings.diff

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1631171] implement warnings module in C

[Brett Cannon]

Changes by Brett Cannon:


Removed file: http://bugs.python.org/file7709/_warnings.c

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1631171] implement warnings module in C

[Brett Cannon]

Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8495/_warnings.c

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1631171] implement warnings module in C

[Brett Cannon]

Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8496/c_warnings.diff

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1631171] implement warnings module in C

[Brett Cannon]

Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8557/_warnings.c

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1631171] implement warnings module in C

[Brett Cannon]

Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8565/_warnings.c

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1631171] implement warnings module in C

[Brett Cannon]

Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8772/test_warnings.py

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1631171] implement warnings module in C

[Brett Cannon]

Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8783/warnings.diff

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1631171] implement warnings module in C

[Brett Cannon]

Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8858/_warnings.diff

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1089358] need siginterrupt() on Linux - impossible to do timeouts

[Ralf Schmitt]

Ralf Schmitt added the comment:

I've attached a new patch against current trunk, which now also contains
unit tests.

--
type:  -> feature request
versions:  -Python 2.5
Added file: http://bugs.python.org/file9491/siginterrupt+tests.txt

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2135] Restructure import.c into PEP 302 importer objects

[Douglas Greiman]

Douglas Greiman added the comment:

Brett,

I wrote my patch thinking that the next step would be to rewrite
DirectoryImporter in Python.  If you're already working on that and
just want to skip straight from point A to point C and skip this point
B, I'm fine with that.  Basically, tell me if you want me to pursue
this further or drop it.  Are you also reimplementing the code for
builtin and frozen modules in Python?

Alexander,

The const thing: I went on a bit of a const rampage after an
especially irritating debugging session involving function side
effects.  They could be removed.

The non-subclassable aspect was an oversight.  I thought about having
a common base class but ended up creating the ModuleInfo helper class
instead.  There's still a few bits of code duplication between the two
importer classes.  16x2 lines in  *_find_module() could be pulled into
a common place, 4x2 lines of *_require_module(), and a few lines in
the various methods.  I wanted to err on the side of introducing as
few new classes as possible to minimize the general scariness of this
patch.

I don't have a Mac setup, but I think the error you're seeing is
actually an error in my test code.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1540617] Use Py_ssize_t for rangeobject members

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

issue1546078 presents a much more ambitious patch - supporting arbitrary 
longs in range.  It looks like that patch was applied to py3k branch 
where performance issues are not yet a concern.

Unless there are plans to backport 1546078, I would like to see this 
patch  make it in 2.6.  (On 64-bit platforms, it is probably as good as 
supporting arbitrary longs and thus will make 2.6 closer to 3.0.)

The patch is still valid for the trunk.

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1540617] Use Py_ssize_t for rangeobject members

[Raymond Hettinger]

Raymond Hettinger added the comment:

FWIW, the current Py2.6 code for enumerate() and itertools.count() both
show how to support arbitrary longs without killing the performance of
common cases.

--
nosy: +rhettinger

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1957] [patch] syslogmodule: Release GIL when calling syslog(3)

[A.M. Kuchling]

Changes by A.M. Kuchling:


--
keywords: +easy

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1877] unhelpful error when calling "python "

[Nick Coghlan]

Nick Coghlan added the comment:

If main.c doesn't handle sys.exit() correctly for code run via
RunMainFromImporter, then that's a problem with the main function - it
will happen regardless of whether it is runpy.py or application code
that calls sys.exit. But as far as I can tell, it handles it just fine -
the SystemExit exception is converted to an error return from
PyObject_Call, which then flows back up the C stack as an error return
from each relevant function call in main.c (until it gets back to the
shell with a non-zero return code from the main function).

And I don't understand your complaint about the Py_None return
conflicting with the comment on that if statement: PyImport_GetImporter
will return Py_None for a directory name, as directories are handled by
the builtin machinery. If PyImport_GetImporter fails completely it will
return NULL - if the function returns anything else, then PyImport
thinks the passed in string is a legitimate sys.path entry (i.e. usable
as an import source).

The *only* difference issue3125 (or Brett's import_in_py branch) would
make to any of this is that PyImport_GetImporter won't return Py_None
anymore. In either case, the additional try/except in runpy would still
be necessary in order to intercept the ImportError when looking for the
module to be executed and convert it to something a bit more explicit.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2135] Restructure import.c into PEP 302 importer objects

[Brett Cannon]

Brett Cannon added the comment:

On Fri, Feb 22, 2008 at 5:21 PM, Douglas Greiman <[EMAIL PROTECTED]> wrote:
>
>  Douglas Greiman added the comment:
>
>  Brett,
>
>  I wrote my patch thinking that the next step would be to rewrite
>  DirectoryImporter in Python.  If you're already working on that and
>  just want to skip straight from point A to point C and skip this point
>  B, I'm fine with that.  Basically, tell me if you want me to pursue
>  this further or drop it.

You can drop it if you want, but I just don't know how long it will
take for me to finish the bootstrap work (for instance I am having to
rewrite the warnings module in C). So there is a chance it might still
be useful, but I can't guarantee it.

>  Are you also reimplementing the code for
>  builtin and frozen modules in Python?
>

I use the imp module to handle the actual loading, but the importers
and loaders are all in Python. You can see the implementation in the
sandbox under import_in_py.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1540617] Use Py_ssize_t for rangeobject members

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Yes, index/longindex optimization is nice and can be applied to xrange.  
However, I don't think python-dev will be happy with the 1546078-style 
changes going to 2.6 and optimization patches are probably premature for 
3.0.

The ssize_t approach has a nice property of not affecting 32-bit 
platforms where objects with offsets >2**31 cannot exist and will 
satisfy most of the needs on 64-bit platforms.

I cannot think of a use case for xrange output that cannot be used as 
index.  On the other hand, such functionality would be trivial to 
implement if needed by an application:

def range(start, stop, step): 
i = start 
while i < stop: 
yield i 
i += step


Maybe you could mark this issue as "easy" and see if the patch can be 
reviewed in one of the bugs days?

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2135] Restructure import.c into PEP 302 importer objects

[Nick Coghlan]

Nick Coghlan added the comment:

Interesting - I'll try to find the time to take a look at this. (I also
added PJE to the nosy list - hopefully he will get a chance to look at it)

--
nosy: +ncoghlan, pje

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1877] unhelpful error when calling "python "

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Nick, you are right about sys.exit().  I did to much C programming 
lately and forgot that sys.exit() does not exit. :-)

I understood your comment as saying that 'importer' points to a valid 
importer.  Now I understand that with the present state of the code, 
that would only be the case when running a zip file.  Now it all makes 
sense.

I still wonder if the case of a bona fide importer could be handled 
without a sys.path mutating trick by simply calling importer-
>find_module.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1877] unhelpful error when calling "python "

[Nick Coghlan]

Nick Coghlan added the comment:

The mutation of sys.path is deliberate - the use case is to allow the
interpreter to execute a zipfile directly and have access to all of the
Python modules and packages bundled along with __main__.py. Supporting
execution of directories as well makes it much easier to test your
application before bundling it that way (since you can test with the
directory till it works, zip the directory, test with the zipfile, then
distribute it).

You can find more details on this feature in issue 1739468

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1739468] Allow interpreter to execute a zip file

[Nick Coghlan]

Nick Coghlan added the comment:

Updated issue title to reflect what was actually implemented

--
title: Add a -z interpreter flag to execute a zip file -> Allow interpreter to 
execute a zip file

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1739468] Allow interpreter to execute a zip file

[Nick Coghlan]

Changes by Nick Coghlan:


Removed file: http://bugs.python.org/file8767/runmain_with_tests.diff

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com