Re: [Python-Dev] relative import circular problem

2013-04-05 Thread Kristján Valur Jónsson
+1. I was thinking along the same lines.
Allowing relative imports in "import module [as X]" statements.
If 'module' consists of pure dots, then "as X" is required.
Otherwise, if "as X" is not present, strip the leading dot(s) when assigning 
the local name.
K

> -Original Message-
> From: Python-Dev [mailto:python-dev-
> [email protected]] On Behalf Of Richard
> Oudkerk
> Sent: 4. apríl 2013 16:26
> To: [email protected]
> Subject: Re: [Python-Dev] relative import circular problem
> 
>
 
> How about having a form of relative import which only works for
> submodules.  For instance, instead of
> 
>  from . import moduleX
> 
> write
> 
>  import .moduleX
> 
> which is currently a SyntaxError.  I think this could be implemented as
> 
>  moduleX = importlib.import_module('.moduleX', __package__)
> 
> --
> 


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] relative import circular problem

2013-04-05 Thread Kristján Valur Jónsson


> -Original Message-
> From: PJ Eby [mailto:[email protected]]
> Sent: 4. apríl 2013 20:29
> To: Guido van Rossum
> Cc: Kristján Valur Jónsson; Nick Coghlan; [email protected]
> Subject: Re: [Python-Dev] relative import circular problem
> 
> So, this is actually an implementation quirk that could be fixed in a
> (somewhat) straightforward manner: by making "from a import b" succeed if
> 'a.b' is in sys.modules, the same way "import a.b" does.  It would require a
> little bit of discussion to hash out the exact way to do it, but it could be 
> done.

Yes, except that "from a import b" is not only used to import modules.  It is 
pretty much defined to mean "b = getattr(a, 'b')".  Consider this module:
#foo.py
# pull helper.helper from its implementation place
from .helper import helper

now, "from foo import helper" is expected to get the helper() function, not the 
helper module, but changing the semantics of the import statement would be 
"surprising".
K

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] relative import circular problem

2013-04-05 Thread Kristján Valur Jónsson
And I should learn to read the entire thread before I start responding.
Cheers!
K

> -Original Message-
> From: Python-Dev [mailto:python-dev-
> [email protected]] On Behalf Of Guido van
> Rossum
> Sent: 4. apríl 2013 22:47
> To: Brett Cannon
> Cc: PJ Eby; Nick Coghlan; [email protected]
> Subject: Re: [Python-Dev] relative import circular problem
> 
> +1 on Brett and PJE just doing this.
> 


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Slides from today's parallel/async Python talk

2013-04-05 Thread Trent Nelson
On Thu, Apr 04, 2013 at 11:53:01PM -0700, Charles-Fran?ois Natali wrote:
> Hello,
> 
> >> async.submit_work(func, args, kwds, callback=None, errback=None)
> >>
> >> How do you implement arguments passing and return value?
> >>
> >> e.g. let's say I pass a list as argument: how do you iterate on the
> >> list from the worker thread without modifying the backing objects for
> >> refcounts (IIUC you use a per-thread heap and don't do any
> >> refcounting).
> >
> > Correct, nothing special is done for the arguments (apart from
> > incref'ing them in the main thread before kicking off the parallel
> > thread (then decref'ing them in the main thread once we're sure the
> > parallel thread has finished)).
> 
> IIUC you incref the argument from the main thread before publishing it
> to the worker thread: but what about containers like list? How do you
> make sure the refcounts of the elements don't get deallocated while
> the worker thread iterates?

Ah, so, all of my examples were missing async.run().  They should
have looked like this:

async.submit_work(foo)
async.submit_work(bar)
async.run()

async.run() is called from the main thread, with the GIL held, and
it blocks until all parallel threads (well, parallel contexts, to be
exact) have completed.  The parallel 'work' doesn't actually start
until async.run() is called either.  (That's completely untrue at
the moment; async.submit_work(foo) will execute foo() in a parallel
thread immediately.  Fixing that is on the todo list.)

With only parallel threads running, no main-thread objects could
ever be deallocated*, as no decref'ing is ever done.

[*]: unless you went out of your way to delete/deallocate main
thread objects via the @async.call_from_main_thread facility.  At
the moment, that's firmly in the category of "Don't Do That".

(And, thinking about it a little more, I guess I could augment the
 ceval loop in such a way that in order for the main thread to run
 things scheduled via @async.call_from_main_thread, all parallel
 threads need to be suspended.  Or I could just freeze/thaw them
 (although I don't know if there are POSIX counterparts to those
 Windows methods).  That would definitely impede performance, but
 it would assure data integrity.  Perhaps it should be enabled by
 default, with the option to disable it for consenting adults.)

> More generally, how do you deal with non-local objects?

Read-only ops against non-local (main-thread) objects from parallel
threads are free, which is nice.  Things get tricky when you try to
mutate main-thread objects from parallel threads.  That's where all
the context persistence, interlocked data types, object protection
etc stuff comes in.

Is... that what you mean by how do I deal with non-local objects?
I took a guess ;-)

Regards,

Trent.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Summary of Python tracker Issues

2013-04-05 Thread Python tracker

ACTIVITY SUMMARY (2013-03-29 - 2013-04-05)
Python tracker at http://bugs.python.org/

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

Issues counts and deltas:
  open3905 (+20)
  closed 25508 (+47)
  total  29413 (+67)

Open issues with patches: 1729 


Issues opened (48)
==

#17425: Update OpenSSL versions in Windows builds
http://bugs.python.org/issue17425  reopened by pitrou

#17574: pysetup failing with "OSError: [Errno 18] Invalid cross-device
http://bugs.python.org/issue17574  opened by vaab

#17575: HTTPConnection.send
http://bugs.python.org/issue17575  opened by [email protected]

#17576: PyNumber_Index() is not int-subclass friendly (or operator.ind
http://bugs.python.org/issue17576  opened by barry

#17577: Add lookahead/peek wrapper to itertools
http://bugs.python.org/issue17577  opened by pconnell

#17580: ctypes: ARM hardfloat argument corruption calling functions wi
http://bugs.python.org/issue17580  opened by bivab

#17582: xml.etree.ElementTree does not preserve whitespaces in attribu
http://bugs.python.org/issue17582  opened by piro

#17583: IDLE HOWTO
http://bugs.python.org/issue17583  opened by Amit.Saha

#17585: IDLE - regression with exit() and quit()
http://bugs.python.org/issue17585  opened by roger.serwy

#17588: runpy cannot run Unicode path on Windows
http://bugs.python.org/issue17588  opened by Drekin

#17589: Make documentation about  macros in C API explicit about rvalu
http://bugs.python.org/issue17589  opened by larry

#17590: mingw: translate gcc internal defines to python platform speci
http://bugs.python.org/issue17590  opened by rpetrov

#17592: mingw: configure MACHDEP and platform for build
http://bugs.python.org/issue17592  opened by rpetrov

#17593: mailbox.py tries to link even on filesystem wihch does not sup
http://bugs.python.org/issue17593  opened by dominik-stadler

#17594: mingw: preset configure defaults
http://bugs.python.org/issue17594  opened by rpetrov

#17595: mingw: configure largefile support for windows builds
http://bugs.python.org/issue17595  opened by rpetrov

#17596: mingw: add wincrypt.h in Python/random.c
http://bugs.python.org/issue17596  opened by rpetrov

#17597: mingw: add $srcdir/PC to CPPFLAGS
http://bugs.python.org/issue17597  opened by rpetrov

#17598: mingw: init system calls
http://bugs.python.org/issue17598  opened by rpetrov

#17599: mingw: detect REPARSE_DATA_BUFFER
http://bugs.python.org/issue17599  opened by rpetrov

#17600: mingw: build-in windows modules (winreg)
http://bugs.python.org/issue17600  opened by rpetrov

#17601: mingw: determine if pwdmodule should be used
http://bugs.python.org/issue17601  opened by rpetrov

#17602: mingw: default sys.path calculations for windows  platforms
http://bugs.python.org/issue17602  opened by rpetrov

#17603: AC_LIBOBJ replacement of fileblocks
http://bugs.python.org/issue17603  opened by rpetrov

#17604: mingw: use main() to start execution
http://bugs.python.org/issue17604  opened by rpetrov

#17605: mingw-meta: build interpeter core
http://bugs.python.org/issue17605  opened by rpetrov

#17606: xml.sax.saxutils.XMLGenerator cannot output with the correct e
http://bugs.python.org/issue17606  opened by neoecos

#17607: missed peephole optimization (unnecessary jump at end of funct
http://bugs.python.org/issue17607  opened by Neal.Norwitz

#17611: Move unwinding of stack for "pseudo exceptions" from interpret
http://bugs.python.org/issue17611  opened by Mark.Shannon

#17612: hooks/mail.py requires [smtp] host to be set, despite a commen
http://bugs.python.org/issue17612  opened by eric.smith

#17613: IDLE "AttributeError: 'NoneType' object has no attribute 'inde
http://bugs.python.org/issue17613  opened by rhettinger

#17615: String comparison performance regression
http://bugs.python.org/issue17615  opened by Neil.Hodgson

#17616: wave.Wave_read and wave.Wave_write can be context managers
http://bugs.python.org/issue17616  opened by Claudiu.Popa

#17618: base85 encoding
http://bugs.python.org/issue17618  opened by pitrou

#17620: Python interactive console doesn't use sys.stdin for input
http://bugs.python.org/issue17620  opened by Drekin

#17621: Create a lazy import loader mixin
http://bugs.python.org/issue17621  opened by brett.cannon

#17626: set's __isub__ doesn't support non-sets.
http://bugs.python.org/issue17626  opened by Roy.Wellington

#17627: Datetime and time doesn't update timezone in a running Win app
http://bugs.python.org/issue17627  opened by cm

#17628: str==str: compare the first and last character before calling 
http://bugs.python.org/issue17628  opened by haypo

#17630: Create a pure Python zipfile importer
http://bugs.python.org/issue17630  opened by brett.cannon

#17631: inspect getsource does not display full text of lambda
http://bugs.python.org/issue17631  opened by Alexey.Spiridonov

#17633: zipimport's handling of namespace packages is incorrect
http://bugs.python.org/issue17633 

[Python-Dev] Is file.readlines(sizehint=N) broken on 2.7?

2013-04-05 Thread Giampaolo Rodolà
with open('test-xxx', 'w') as f:
f.write('aaa\nbbb\nccc')
with open('test-xxx', 'r') as f:
print(f.readlines(1))

On Python 3.3 I get:

['aaa\n']

...while on Python 2.7:

['aaa\n', 'bbb\n', 'ccc']


Is this a bug or I'm missing something?


--- Giampaolo
https://code.google.com/p/pyftpdlib/
https://code.google.com/p/psutil/
https://code.google.com/p/pysendfile/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Is file.readlines(sizehint=N) broken on 2.7?

2013-04-05 Thread INADA Naoki
The builtin open() was replaced with io.open().
It's difference between file.readlines() and io.IOBase.readlines().


On Sat, Apr 6, 2013 at 2:15 AM, Giampaolo Rodolà  wrote:

> with open('test-xxx', 'w') as f:
> f.write('aaa\nbbb\nccc')
> with open('test-xxx', 'r') as f:
> print(f.readlines(1))
>
> On Python 3.3 I get:
>
> ['aaa\n']
>
> ...while on Python 2.7:
>
> ['aaa\n', 'bbb\n', 'ccc']
>
>
> Is this a bug or I'm missing something?
>
>
> --- Giampaolo
> https://code.google.com/p/pyftpdlib/
> https://code.google.com/p/psutil/
> https://code.google.com/p/pysendfile/
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
>



-- 
INADA Naoki  
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Is file.readlines(sizehint=N) broken on 2.7?

2013-04-05 Thread Giampaolo Rodolà
2013/4/5 INADA Naoki :
> The builtin open() was replaced with io.open().
> It's difference between file.readlines() and io.IOBase.readlines().

Should that justify this difference in behavior?
Apparently on 2.X sizehint does not have any effect as far as I can see.

--- Giampaolo
https://code.google.com/p/pyftpdlib/
https://code.google.com/p/psutil/
https://code.google.com/p/pysendfile/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Is file.readlines(sizehint=N) broken on 2.7?

2013-04-05 Thread Guido van Rossum
It's a *hint*, remember? :-) It does work, it's just rounded up to a
fairly large number in some implementations.

On Fri, Apr 5, 2013 at 11:24 AM, Giampaolo Rodolà  wrote:
> 2013/4/5 INADA Naoki :
>> The builtin open() was replaced with io.open().
>> It's difference between file.readlines() and io.IOBase.readlines().
>
> Should that justify this difference in behavior?
> Apparently on 2.X sizehint does not have any effect as far as I can see.
>
> --- Giampaolo
> https://code.google.com/p/pyftpdlib/
> https://code.google.com/p/psutil/
> https://code.google.com/p/pysendfile/
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Is file.readlines(sizehint=N) broken on 2.7?

2013-04-05 Thread R. David Murray
On Fri, 05 Apr 2013 20:24:43 +0200, =?ISO-8859-1?Q?Giampaolo_Rodol=E0?= 
 wrote:
> 2013/4/5 INADA Naoki :
> > The builtin open() was replaced with io.open().
> > It's difference between file.readlines() and io.IOBase.readlines().
> 
> Should that justify this difference in behavior?

Yes.  The 'file' documentation for readlines says documents that the
argument is advisory and may be rounded up to an internal buffer size.

io's readlines, on the other hand, says no more lines will be read if
the total size of bytes read so far exceeds the hint.

So, different semantics.

> Apparently on 2.X sizehint does not have any effect as far as I can see.

Have you played with large enough hints/small enough buffers?

--David

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Is file.readlines(sizehint=N) broken on 2.7?

2013-04-05 Thread Giampaolo Rodolà
2013/4/5 R. David Murray :
> On Fri, 05 Apr 2013 20:24:43 +0200, =?ISO-8859-1?Q?Giampaolo_Rodol=E0?= 
>  wrote:
>> 2013/4/5 INADA Naoki :
>> > The builtin open() was replaced with io.open().
>> > It's difference between file.readlines() and io.IOBase.readlines().
>>
>> Should that justify this difference in behavior?
>
> Yes.  The 'file' documentation for readlines says documents that the
> argument is advisory and may be rounded up to an internal buffer size.
>
> io's readlines, on the other hand, says no more lines will be read if
> the total size of bytes read so far exceeds the hint.
>
> So, different semantics.

I see.

>> Apparently on 2.X sizehint does not have any effect as far as I can see.
>
> Have you played with large enough hints/small enough buffers?

Right, it seems it tends to change around 8196 bytes.
Ok then, nevermind.


--- Giampaolo
https://code.google.com/p/pyftpdlib/
https://code.google.com/p/psutil/
https://code.google.com/p/pysendfile/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Fix typo

2013-04-05 Thread Eli Bendersky
On Fri, Apr 5, 2013 at 1:40 AM, andrew.svetlov
wrote:

> http://hg.python.org/cpython/rev/6cf485ffd325
> changeset:   83110:6cf485ffd325
> parent:  83106:94fb906e5899
> parent:  83109:9610ede72ed2
> user:Andrew Svetlov 
> date:Fri Apr 05 11:40:01 2013 +0300
> summary:
>   Fix typo
>
> files:
>   Doc/howto/argparse.rst |  2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/Doc/howto/argparse.rst b/Doc/howto/argparse.rst
> --- a/Doc/howto/argparse.rst
> +++ b/Doc/howto/argparse.rst
> @@ -668,7 +668,7 @@
>  So far, we have been working with two methods of an
>  :class:`argparse.ArgumentParser` instance. Let's introduce a third one,
>  :meth:`add_mutually_exclusive_group`. It allows for us to specify options
> that
> -conflict with each other. Let's also change the rest of the program make
> the
> +conflict with each other. Let's also change the rest of the program to
> make the
>  new functionality makes more sense:
>
 

Andrew, while you're at it you can also fix the rest of the sentence, which
makes no sense ;-)

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com