[Python-Dev] Question about code in test_email/test_message.py

I'm writing up a PR for an issue I created and adding a test to test/test_email/test_message.py In that file there is a variable named message_params that is initialized with about 15 different sets of test data, in class TestEmailMessageBase, but is never referenced again. I even grepped for t

[Python-Dev] Question for potential python development contributions on Windows

The Python Developers Guide specifically states to get VS2017 for developing or enhancing python on a Windows system. Is it still correct to specifically use VS2017 , or is VS2019 also acceptable? I ask this because I know that the *.vcproj files and other build-environment files have chang

[Python-Dev] Question regarding the value of PyThreadState.thread_id

Hi all. My apologies if this is a topic that's been discussed already, but I wasn't able to locate anything in the archive on the subject. I was wondering if there's a fundamental reason for using PyThread_get_thread_ident instead of PyThread_get_thread_native_id for the value of the thread_id fie

[Python-Dev] Question about bytecode stability

I'm getting ready to get back into an old personal project with some new ideas. Before I do, I need to ask a question regarding the stability of CPython bytecode. Before you say it, I am well aware and fully understand that the opcodes may change in value and semantics between 3.x and 3.(x+1) witho

[Python-Dev] Question: how to extend standard Python library to add new functionalities?

Daniel, Your question seems to be a request for help in writing the extension. This list is for discussion and improvement of proposed implementations. For help in writing the code, the python-corementorship list is a better venue. If your question is for help in designing the extension, and de

[Python-Dev] Question: how to extend standard Python library to add new functionalities?

Hi all, I want to add openssl engine in Python SSL library. I know that if the new functions can be added in Python we can inherit existing class (such as ssl). However, It seems the SSL module extends _SSL module which is written in C. I'm not sure how can I extend SSL module in this situation

[Python-Dev] Question on handling of per-thread async exception with global pending.async_exc flag

Hi, I am trying to understand the way that async exceptions are handled between _PyEval_EvalFrameDefault (in ceval.c) and PyThreadState_SetAsyncExc (pystate.c). In ceval.c, the eval loop determines whether to check for async exception for the current thread based on the global _PyRuntime.ceval.ev

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

On 20/02/2019 18:58, Victor Stinner wrote: > If Python 3.4 was the current version when a bug was reported, I would > expect the version field of the bug set to Python 3.4. Maybe the bug > has been fixed in the meanwhile, maybe not. Closing all bugs affected > to 3.4 is a risk of loosing useful inf

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

Hi, If Python 3.4 was the current version when a bug was reported, I would expect the version field of the bug set to Python 3.4. Maybe the bug has been fixed in the meanwhile, maybe not. Closing all bugs affected to 3.4 is a risk of loosing useful information on real bugs: closed bugs are ignored

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

Hi Steve, I reply on the mailing list On 02/20, Steve Dower wrote: It'll make same noise, sure, but if we schedule a bulk close of issues that have not been touched since 3.6 was released then at least it'll be easy to "mark all as read". And searching for current issues will become easier. As

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

I am against a mass changing the status of issue, since this will generate an enormous amount of noise (to me at least). But you are free to update issues one by one if you can to do some progress with them. Sure, I don't want to update them massively, just one by one. But I prefer to ask befor

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

20.02.19 17:01, Stephane Wirtel пише: As you know, Python 3.4 and 3.5 are in security mode and the EOL for these versions are respectively 2019-03-16 and 2020-09-13. Number of issues 3.4: 1530 issues 3.5: 1901 issues But some issues are not related to the security. Could we update these issue

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

On 20Feb.2019 0711, Stephane Wirtel wrote: > After discussion with Victor, my proposal will generate noise with the > ML, maybe for nothing. > > On 02/20, Stephane Wirtel wrote: >> Hi, >> >> As you know, Python 3.4 and 3.5 are in security mode and the EOL for >> these versions are respectively 201

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

After discussion with Victor, my proposal will generate noise with the ML, maybe for nothing. On 02/20, Stephane Wirtel wrote: Hi, As you know, Python 3.4 and 3.5 are in security mode and the EOL for these versions are respectively 2019-03-16 and 2020-09-13. Number of issues 3.4: 1530 issues

[Python-Dev] Question - Bug Triage for 3.4 & 3.5

Hi, As you know, Python 3.4 and 3.5 are in security mode and the EOL for these versions are respectively 2019-03-16 and 2020-09-13. Number of issues 3.4: 1530 issues 3.5: 1901 issues But some issues are not related to the security. Could we update these issues (non-security) to 3.6/3.7 & 3.8?

Re: [Python-Dev] Question about PEP 484

Hi Sebastian, Both Teddy (cc'd) and I would like to volunteer to help. We're excited about the prospect of an informational pyi PEP. Best, Rebecca On Tue, Jul 17, 2018 at 10:42 AM 'Adam Cataldo' via pytype < pyt...@googlegroups.com> wrote: > Hi Sebastian, > > Of course, we'd be happy to work wi

Re: [Python-Dev] Question about PEP 484

Great Jelle! We look forward to working with you to. On Tue, Jul 17, 2018 at 10:41 AM Jelle Zijlstra wrote: > > > 2018-07-17 9:55 GMT-07:00 Sebastian Rittau : > >> On 17.07.2018 17:05, Guido van Rossum wrote: >> >>> This is a good point. I presume specifying this unambiguously would be a >>> hug

Re: [Python-Dev] Question about PEP 484

Hi Sebastian, Of course, we'd be happy to work with you on this! We just need to figure out which of us will drive this on our end (most likely Rebecca or Teddy). I'll huddle with the team and get back to you with an answer on who later today. On Tue, Jul 17, 2018 at 9:58 AM Sebastian Rittau

Re: [Python-Dev] Question about PEP 484

2018-07-17 9:55 GMT-07:00 Sebastian Rittau : > On 17.07.2018 17:05, Guido van Rossum wrote: > >> This is a good point. I presume specifying this unambiguously would be a >> huge amount of work, and it would mostly codify mypy's current behavior. I >> don't think that's within the scope of PEP 484,

Re: [Python-Dev] Question about PEP 484

On 17.07.2018 17:05, Guido van Rossum wrote: This is a good point. I presume specifying this unambiguously would be a huge amount of work, and it would mostly codify mypy's current behavior. I don't think that's within the scope of PEP 484, but it could well be done as a separate PEP (perhaps a

Re: [Python-Dev] Question about PEP 484

This is a good point. I presume specifying this unambiguously would be a huge amount of work, and it would mostly codify mypy's current behavior. I don't think that's within the scope of PEP 484, but it could well be done as a separate PEP (perhaps an informational one?). I hope you understand that

Re: [Python-Dev] Question about PEP 484

On 16.07.2018 19:21, Adam Cataldo via Python-Dev wrote: * * One thing we care about in particular, given the implementation of pytype, is the detailed definition of what goes in a .pyi file. Do folks think this makes sense to include as part of PEP 484, or would this be better

Re: [Python-Dev] Question about PEP 484

Thanks, Rebecca! So the status of PEP 484 is that we don't want to add new features to it -- those require their own PEP. But we do accept PRs for clarifications, assuming the clarifications are about issues where the intention is clear but the text is not (usually because we thought there was only

Re: [Python-Dev] Question about PEP 484

Hi Guido and all, Let me try to clarify our (pytype team's) intentions a bit. Our overall goal is to see PEP 484 finalized, in the interest of having a definitive type-checking reference to point to and work off of. We're willing and eager to help with this, if we get some guidance on what the aut

Re: [Python-Dev] Question about PEP 484

On Mon, Jul 16, 2018 at 2:56 PM, Gregory P. Smith wrote: > > On Mon, Jul 16, 2018 at 1:44 PM Guido van Rossum wrote: > >> As one of the authors of PEP 484, *I* never thought there was an >> ambiguity here. The intention was for stub files to conform to the same >> grammar as regular .py files, b

Re: [Python-Dev] Question about PEP 484

On Mon, Jul 16, 2018 at 1:44 PM Guido van Rossum wrote: > As one of the authors of PEP 484, *I* never thought there was an ambiguity > here. The intention was for stub files to conform to the same grammar as > regular .py files, but with a different interpretation. > > > "Have the same syntax as

Re: [Python-Dev] Question about PEP 484

2018-07-16 10:21 GMT-07:00 Adam Cataldo via Python-Dev < python-dev@python.org>: > > > > > > *Hi Folks,Cc: Rebecca, pytypeThis is Adam Cataldo; I’m the engineering > manager for the Python team at Google. Rebecca Chen, our lead pytype > contributor, and I are int

Re: [Python-Dev] Question about PEP 484

As one of the authors of PEP 484, *I* never thought there was an ambiguity here. The intention was for stub files to conform to the same grammar as regular .py files, but with a different interpretation. > "Have the same syntax as regular Python modules" and "are files containing type hints" are a

Re: [Python-Dev] Question about PEP 484

Thanks Brett and Teddy, Just so it doesn't get lost in the shuffle as folks dive into details, I'll re-ask my earlier question about stub files. Assuming there is consensus that there is ambiguity to resolve in the current definition, is updating the section on stub files the preferred option? The

Re: [Python-Dev] Question about PEP 484

Hi, my name is Teddy Sudol. I work with Adam and Rebecca on pytype. The explanation of stub files is unclear. The section you linked starts with, "Stub files are files containing type hints that are only for use by the type checker, not at runtime." According to https://www.python.org/dev/peps/pep

Re: [Python-Dev] Question about PEP 484

On Mon, 16 Jul 2018 at 10:32 Adam Cataldo via Python-Dev < python-dev@python.org> wrote: > > > > > > *Hi Folks,Cc: Rebecca, pytypeThis is Adam Cataldo; I’m the engineering > manager for the Python team at Google. Rebecca Chen, our lead pytype > contributor, and I

[Python-Dev] Question about PEP 484

*Hi Folks,Cc: Rebecca, pytypeThis is Adam Cataldo; I’m the engineering manager for the Python team at Google. Rebecca Chen, our lead pytype contributor, and I are interested in helping finalize PEP 484 if possible. To that end, we wanted to find out what technical

Re: [Python-Dev] Question on a seemingly useless doctest

Sorry, completely fat-fingered my autocomplete and sent to to wrong list. On Tue, Dec 19, 2017 at 12:12 PM, Erik Bray wrote: > Hi all, > > I have a ticket [1] that's hung up on a failure in one doctest in the > form of sage.doctest.sources.FileDocTestSource._test_enough_doctests. > > This test ha

[Python-Dev] Question on a seemingly useless doctest

Hi all, I have a ticket [1] that's hung up on a failure in one doctest in the form of sage.doctest.sources.FileDocTestSource._test_enough_doctests. This test has been there since, it seems, as long as the current doctest framework has been in place and nobody seems to have questioned it. Its exp

Re: [Python-Dev] [Question][Asyncio] Process + Threads + asyncio... has sense?

Oks. Thank you very much. --- *Daniel García (cr0hn)* Security researcher and ethical hacker *Personal site*: http://cr0hn.com *Linkedin*: https://www.linkedin.com/in/garciagarciadaniel *Company*: http://abirtone.com *Twitter*: @ggdaniel El día 18 de abril de 2016

Re: [Python-Dev] [Question][Asyncio] Process + Threads + asyncio... has sense?

A better place for this question would be the tulip Google group: https://groups.google.com/forum/#!forum/python-tulip On Mon, Apr 18, 2016 at 3:05 AM, cr0hn wrote: > Hi all, > > It's the first time I write in this list. Sorry if it's not the best place > for this question. > > After I read the

[Python-Dev] [Question][Asyncio] Process + Threads + asyncio... has sense?

Hi all, It's the first time I write in this list. Sorry if it's not the best place for this question. After I read the Asyncio's documentation, PEPs, Guido/Jesse/David Beazley articles/talks, etc, I developed a PoC library that mixes: Process + Threads + Asyncio Tasks, doing an scheme like this d

Re: [Python-Dev] Question about the current implementation of str

2016-04-09 9:52 GMT+02:00 Victor Stinner : > But the hash is used as an heuristic to decide if a string is "immutable" or > not, the refcount is also used by the heuristic. If the string is immutable, > an operation like resize must create a new string. I'm talking about this private function: st

Re: [Python-Dev] Question about the current implementation of str

On 09.04.16 10:52, Victor Stinner wrote: Le 9 avr. 2016 03:04, "Larry Hastings" mailto:la...@hastings.org>> a écrit : > Although the str object is immutable from Python's perspective, the C object itself is mutable. For example, for dynamically-created strings the hash field may be lazy-compute

Re: [Python-Dev] Question about the current implementation of str

Le 9 avr. 2016 03:04, "Larry Hastings" a écrit : > Although the str object is immutable from Python's perspective, the C object itself is mutable. For example, for dynamically-created strings the hash field may be lazy-computed and cached inside the object. Yes, the hash is computed once on dema

Re: [Python-Dev] Question about the current implementation of str

On 9 April 2016 at 10:56, Larry Hastings wrote: > > > I have a straightforward question about the str object, specifically the > PyUnicodeObject. I've tried reading the source to answer the question > myself but it's nearly impenetrable. So I was hoping someone here who > understands the current

[Python-Dev] Question about the current implementation of str

I have a straightforward question about the str object, specifically the PyUnicodeObject. I've tried reading the source to answer the question myself but it's nearly impenetrable. So I was hoping someone here who understands the current implementation could answer it for me. Although the

Re: [Python-Dev] Question about sys.path and sys.argv and how packaging (may) affects default values

On 2016-03-02 18:45, Thomas Wouters wrote: On Wed, Mar 2, 2016 at 3:50 AM, Michael Felt wrote: Hello all, 1) There are many lists to choose from - if this is the wrong one for questions about packaging - please forgive me, and point me in the right direction. It's hard to say where this bel

Re: [Python-Dev] Question about sys.path and sys.argv and how packaging (may) affects default values

On Wed, Mar 2, 2016 at 3:50 AM, Michael Felt wrote: > Hello all, > > 1) There are many lists to choose from - if this is the wrong one for > questions about packaging - please forgive me, and point me in the right > direction. > It's hard to say where this belongs best, but python-list would pro

Re: [Python-Dev] Question about sys.path and sys.argv and how packaging (may) affects default values

On Wed, 2 Mar 2016 at 09:12 Michael Felt wrote: > Hello all, > > 1) There are many lists to choose from - if this is the wrong one for > questions about packaging - please forgive me, and point me in the right > direction. > So in this instance you're after python-list since this is a general su

[Python-Dev] Question about sys.path and sys.argv and how packaging (may) affects default values

Hello all, 1) There are many lists to choose from - if this is the wrong one for questions about packaging - please forgive me, and point me in the right direction. 2) Normally, I have just packaged python, and then moved on. However, recently I have been asked to help with packaging an 'eas

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

itrou An: python-dev@python.org CC: Gesendet: 11:22 Dienstag, 12.Februar 2013 Betreff: Re: [Python-Dev] Question regarding: Lib/_markupbase.py Le Mon, 11 Feb 2013 11:02:04 -0800, Guido van Rossum a écrit : > Warning: see http://bugs.python.org/issue17170. Depending on the > length of

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

Le Mon, 11 Feb 2013 11:02:04 -0800, Guido van Rossum a écrit : > Warning: see http://bugs.python.org/issue17170. Depending on the > length of the string being scanned and the probability of finding the > specific character, the proposed change could actually be a > *pessimization*. OTOH if the cha

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

Warning: see http://bugs.python.org/issue17170. Depending on the length of the string being scanned and the probability of finding the specific character, the proposed change could actually be a *pessimization*. OTOH if the character occurs many times, the slice will actually cause O(N**2) behavior

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

On Mon, Feb 11, 2013 at 12:16:48PM +, Developer Developer wrote: > I was having a look at the file: Lib/_markupbase.py (@ 82151), function: > "_parse_doctype_element" and have seen something that has caught my attention: > > if '>' in rawdata[j:]: >     return rawdata.find(">", j) + 1 > >

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

Thank you David, I didn't think of the issue tracker. I have just done it. Guido - Ursprüngliche Message - Von: R. David Murray An: Developer Developer CC: "python-dev@python.org" Gesendet: 16:59 Montag, 11.Februar 2013 Betreff: Re: [Python-Dev] Question

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

> Von: Fred Drake > An: Developer Developer > CC: "python-dev@python.org" > Gesendet: 15:10 Montag, 11.Februar 2013 > Betreff: Re: [Python-Dev] Question regarding: Lib/_markupbase.py > > On Mon, Feb 11, 2013 at 7:16 AM, Developer Developer > wrote: > > Would

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

-- Ursprüngliche Message - Von: Fred Drake An: Developer Developer CC: "python-dev@python.org" Gesendet: 15:10 Montag, 11.Februar 2013 Betreff: Re: [Python-Dev] Question regarding: Lib/_markupbase.py On Mon, Feb 11, 2013 at 7:16 AM, Developer Developer wrote: > Wouldn't it

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

On Mon, Feb 11, 2013 at 7:16 AM, Developer Developer wrote: > Wouldn't it be better to do the following? ... > Otherwise I think we are scanning rawdata[j:] twice. Yes, that would be better, and avoids a string object creation as well. -Fred -- Fred L. Drake, Jr. "A storm broke loose in

[Python-Dev] Question regarding: Lib/_markupbase.py

Hello all, I was having a look at the file: Lib/_markupbase.py (@ 82151), function: "_parse_doctype_element" and have seen something that has caught my attention: if '>' in rawdata[j:]:     return rawdata.find(">", j) + 1 Wouldn't it be better to do the following? pos = rawdata.find(">", j) if

Re: [Python-Dev] question about packaging

The current effort seems to be distlib, Vinay's project to gather the "good parts" of packaging and distutils as a library API: http://packages.python.org/distlib/ (there's an active bitbucket repo) See https://bitbucket.org/vinay.sajip/distlib/ for the latest code, which is periodically push

Re: [Python-Dev] question about packaging

Antonio Cavallo cavallinux.eu> writes: > Correct if I'm wrong but distlib isn't targeting resources managent? > distutils is targeted to distribute python modules/packages instead; > small differences but on the field they really mean different things. distlib is intended to target more than r

Re: [Python-Dev] question about packaging

> On Dec 29, 2012, at 5:47 AM, Antoine Pitrou wrote: > > The current effort seems to be distlib, Vinay's project to gather the > > "good parts" of packaging and distutils as a library API: > > http://packages.python.org/distlib/ > > (there's an active bitbucket repo) See https://bitbucket.org/vin

Re: [Python-Dev] question about packaging

On Dec 29, 2012, at 5:47 AM, Antoine Pitrou wrote: > On Fri, 28 Dec 2012 17:59:05 -0500 > Doug Hellmann wrote: >> A couple of us from the OpenStack project are interested in getting involved >> in the packaging rewrite/update project. I was following that work for a >> while, but have lost tra

Re: [Python-Dev] question about packaging

Correct if I'm wrong but distlib isn't targeting resources managent? distutils is targeted to distribute python modules/packages instead; small differences but on the field they really mean different things. distlib is under http://hg.python.org/distlib too :O ..my first guess would be that's

Re: [Python-Dev] question about packaging

On Fri, 28 Dec 2012 17:59:05 -0500 Doug Hellmann wrote: > A couple of us from the OpenStack project are interested in getting involved > in the packaging rewrite/update project. I was following that work for a > while, but have lost track of its current state. Can someone point me to the > righ

Re: [Python-Dev] question about packaging

Is that where the discussions are actively happening? Last time I looked at it I thought there was a google group or something. It's bee quite a while, though, so I may just be confused. On Dec 28, 2012, at 6:12 PM, Antonio Cavallo wrote: > There's the distutil mailing list: > > http://mail.py

Re: [Python-Dev] question about packaging

There's the distutil mailing list: http://mail.python.org/mailman/listinfo/distutils-sig Doug Hellmann wrote: A couple of us from the OpenStack project are interested in getting involved in the packaging rewrite/update project. I was following that work for a while, but have lost track of i

[Python-Dev] question about packaging

A couple of us from the OpenStack project are interested in getting involved in the packaging rewrite/update project. I was following that work for a while, but have lost track of its current state. Can someone point me to the right mailing list, and maybe a status page or something so I can sta

Re: [Python-Dev] question re: default branch and release clone

And if changes like this are added now, they will be included in 3.2.4 but not in 3.3.0. Is this bad? This is the standard for any security fix: such a fix would be added to 3.1.6, 3.2.4, 3.3.1, and 3.4.0, but not to 3.2.3 or 3.3.0. So version(A) > version(B) does not imply has_fix(A, F)

Re: [Python-Dev] question re: default branch and release clone

On 28.08.2012 06:22, Petri Lehtinen wrote: Georg Brandl wrote: Changes to the default branch must be bugfix-only. The 3.4 development only opens when the 3.3 branch is created, which happens after the release of 3.3.0 final. Changes made in default and not cherry-picked to the 3.3.0 release cl

Re: [Python-Dev] question re: default branch and release clone

Georg Brandl wrote: > Changes to the default branch must be bugfix-only. The 3.4 development > only opens when the 3.3 branch is created, which happens after the > release of 3.3.0 final. > > Changes made in default and not cherry-picked to the 3.3.0 release clone > will therefore end up in 3.3.1

Re: [Python-Dev] question re: default branch and release clone

On 26.08.2012 21:15, Chris Jerdonek wrote: Now that the 3.3 release clone has been created, can someone clarify what changes are allowed to go into the default branch? Is it the same policy as if the changes were going into the release clone directly (i.e. code freeze unless you have Georg's app

[Python-Dev] question re: default branch and release clone

Now that the 3.3 release clone has been created, can someone clarify what changes are allowed to go into the default branch? Is it the same policy as if the changes were going into the release clone directly (i.e. code freeze unless you have Georg's approval), or are future changes for 3.3.1 okay,

Re: [Python-Dev] Question

On Sat, Aug 4, 2012 at 4:53 AM, Dheeraj Goswami wrote: > Hi Python Gurus, > I am an experienced Java developer and have been working on it for about 8 > years. I need to build a web 2.0/AJAX based website/application and I am > thinking to build it in Django which means I need to learn and move to

Re: [Python-Dev] Question

On 03/08/2012 19:53, Dheeraj Goswami wrote: Hi Python Gurus, I am an experienced Java developer and have been working on it for about 8 years. I need to build a web 2.0/AJAX based website/application and I am thinking to build it in Django which means I need to learn and move to Python. Please a

[Python-Dev] Question

Hi Python Gurus, I am an experienced Java developer and have been working on it for about 8 years. I need to build a web 2.0/AJAX based website/application and I am thinking to build it in Django which means I need to learn and move to Python. Please advise is it really worth moving from Java wo

Re: [Python-Dev] Question about Module Loading

Nevermind. In 2.6 (what I'm working with) it's "case IMPORT_NAME:" Thank you for letting me know where to start. On 1 June 2011 15:43, Timothy Kadich wrote: > I don't understand what you mean by "TARGET(IMPORT_NAME)". I can't find > that string in ceval.c. > > > On 1 June 2011 12:04, Benjamin Pe

Re: [Python-Dev] Question about Module Loading

I don't understand what you mean by "TARGET(IMPORT_NAME)". I can't find that string in ceval.c. On 1 June 2011 12:04, Benjamin Peterson wrote: > 2011/6/1 Timothy Kadich : > > If a Python program imported a module, say numpy for example, where in > the > > source is this line interpreted and then

Re: [Python-Dev] Question about Module Loading

2011/6/1 Timothy Kadich : > If a Python program imported a module, say numpy for example, where in the > source is this line interpreted and then handled by import.c ? Many different files. Start from TARGET(IMPORT_NAME) in ceval.c. -- Regards, Benjamin _

Re: [Python-Dev] Question about Module Loading

On Wed, 01 Jun 2011 10:54:13 -0700, Timothy Kadich wrote: > If a Python program imported a module, say numpy for example, where in the > source is this line interpreted and then handled by import.c ? Your question is not as simple as you think (I think), but I'm guessing you will want to look at

[Python-Dev] Question about Module Loading

If a Python program imported a module, say numpy for example, where in the source is this line interpreted and then handled by import.c ? Thank you in advance! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/pyth

Re: [Python-Dev] Question about GDB bindings and 32/64 bits

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/11/10 16:46, Matthias Klose wrote: > On 26.11.2010 05:11, Jesus Cea wrote: >> I have installed GDB 7.2 32 bits and 32 bits buildslaves are green. >> Nevertheless 64 bits buildslaves are failing test_gdb. >> >> Is there any expectation that a 32 b

Re: [Python-Dev] Question about GDB bindings and 32/64 bits

On 26.11.2010 05:11, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have installed GDB 7.2 32 bits and 32 bits buildslaves are green. Nevertheless 64 bits buildslaves are failing test_gdb. Is there any expectation that a 32 bits GDB be able to debug a 64 bits python?. If not,

[Python-Dev] Question about GDB bindings and 32/64 bits

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have installed GDB 7.2 32 bits and 32 bits buildslaves are green. Nevertheless 64 bits buildslaves are failing test_gdb. Is there any expectation that a 32 bits GDB be able to debug a 64 bits python?. If not, gdb test should compare "platform.archit

Re: [Python-Dev] Question on imports and packages

FWIW, I also agree with Michael that static analysis would be much preferred. You never know what side effects importing a module has. (This could even be construed as an attack vector.) --Guido On Tue, Nov 2, 2010 at 7:54 PM, Brett Cannon wrote: > On Tue, Nov 2, 2010 at 17:35, Guido van Rossum

Re: [Python-Dev] Question on imports and packages

On Tue, Nov 2, 2010 at 17:35, Guido van Rossum wrote: > If you are importing the code, the __module__ attribute on each class > should tell you where it is actually defined (as opposed to where you > imported it from). Then sys.modules gives you the module object which > has a __file__ attribute,

Re: [Python-Dev] Question on imports and packages

On 02/11/2010 23:44, Raymond Hettinger wrote: Brett, Does the import mechanism for importing packages preserve enough information to be able to figure-out where all the components are defined? I'm wondering if it is possible for the class browser to be built-out to scan/navigate class struct

Re: [Python-Dev] Question on imports and packages

If you are importing the code, the __module__ attribute on each class should tell you where it is actually defined (as opposed to where you imported it from). Then sys.modules gives you the module object which has a __file__ attribute, etc. On Tue, Nov 2, 2010 at 4:44 PM, Raymond Hettinger wrote:

[Python-Dev] Question on imports and packages

Brett, Does the import mechanism for importing packages preserve enough information to be able to figure-out where all the components are defined? I'm wondering if it is possible for the class browser to be built-out to scan/navigate class structure across a module that has been split into a

Re: [Python-Dev] question/comment about documentation of relative imports

Guido van Rossum wrote: Now it is time to withdraw the anti-recommendation. Or at least re-word them all to make it clear that they're talking about the *old* style of relative import in 2.x. -- Greg ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] question/comment about documentation of relative imports

On Wed, Oct 06, 2010 at 07:09:48AM +1000, Nick Coghlan wrote: > The remaining scenarios we have that can lead to duplication of a > module happen regardless of the import style you use*. > > Cheers, > Nick. > > *For the curious - those scenarios relate to ending up with the same > module present

Re: [Python-Dev] question/comment about documentation of relative imports

On Wed, Oct 6, 2010 at 4:21 AM, Guido van Rossum wrote: > On Tue, Oct 5, 2010 at 11:17 AM, Darren Dale wrote: >> The issue is implementing a PEP with nice support for relative >> imports, and then documenting that it should never be used. > > Isn't this mostly historical? Until the new relative-i

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, Oct 5, 2010 at 3:37 PM, Terry Reedy wrote: > On 10/5/2010 2:21 PM, Guido van Rossum wrote: >> >> On Tue, Oct 5, 2010 at 11:17 AM, Darren Dale  wrote: >>> >>> The issue is implementing a PEP with nice support for relative >>> imports, and then documenting that it should never be used. >> >>

Re: [Python-Dev] question/comment about documentation of relative imports

On 10/5/2010 2:21 PM, Guido van Rossum wrote: On Tue, Oct 5, 2010 at 11:17 AM, Darren Dale wrote: The issue is implementing a PEP with nice support for relative imports, and then documenting that it should never be used. Isn't this mostly historical? Until the new relative-import syntax was i

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, Oct 5, 2010 at 11:17 AM, Darren Dale wrote: > The issue is implementing a PEP with nice support for relative > imports, and then documenting that it should never be used. Isn't this mostly historical? Until the new relative-import syntax was implemented there were various problems with re

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, 5 Oct 2010 14:17:47 -0400 Darren Dale wrote: > >> Thats not the point though. Due to compatibility issues, maybe I don't > >> want to expose the code at the top level. Maybe the foo package is > >> distributed elsewhere as a top-level package, but I need to use an > >> older version due to

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, Oct 5, 2010 at 1:45 PM, Antoine Pitrou wrote: > Le mardi 05 octobre 2010 à 13:28 -0400, Darren Dale a écrit : >> >> >> >> As the OP pointed out, for code that may be *included* in other projects >> >> there is no other choice. This is often useful for packages shared >> >> between one or t

Re: [Python-Dev] question/comment about documentation of relative imports

> If they were actively discouraged, perhaps performing a relative > import would raise a warning, This would be done if this import style was deprecated. It’s different from it being discouraged. > or maybe distutils would raise a warning at install time, Distutils does not inspect source files.

Re: [Python-Dev] question/comment about documentation of relative imports

Le mardi 05 octobre 2010 à 13:28 -0400, Darren Dale a écrit : > >> > >> As the OP pointed out, for code that may be *included* in other projects > >> there is no other choice. This is often useful for packages shared > >> between one or two projects that nonetheless don't warrant separate > >> dist

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, Oct 5, 2010 at 12:43 PM, Antoine Pitrou wrote: > On Tue, 05 Oct 2010 17:18:18 +0100 > Michael Foord wrote: >> > >> > Generally I'm +0 on relative imports as a whole. >> >> As the OP pointed out, for code that may be *included* in other projects >> there is no other choice. This is often u

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, 05 Oct 2010 17:18:18 +0100 Michael Foord wrote: > > > > Generally I'm +0 on relative imports as a whole. > > As the OP pointed out, for code that may be *included* in other projects > there is no other choice. This is often useful for packages shared > between one or two projects that n

Re: [Python-Dev] question/comment about documentation of relative imports

On 05/10/2010 17:13, Simon Cross wrote: On Tue, Oct 5, 2010 at 4:56 PM, Darren Dale wrote: from ...sys import path Note that while that last case is legal, it is certainly discouraged ("insane" was the word Guido used). Only if by "legal" you mean "happened to work". It stops "happenin

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, Oct 5, 2010 at 4:56 PM, Darren Dale wrote: >   from ...sys import path > >   Note that while that last case is legal, it is certainly > discouraged ("insane" was the word Guido used). Only if by "legal" you mean "happened to work". It stops "happening to work" in Python 2.6.6. :) General

[Python-Dev] question/comment about documentation of relative imports

I have a couple questions/comments about the use of PEP 328-style relative imports. For example, the faq at http://docs.python.org/py3k/faq/programming.html#what-are-the-best-practices-for-using-import-in-a-module reads: "Never use relative package imports. If you’re writing code that’s in the pac

  1   2   >