Re: [Jobs] Need some help with Python Job Board
Hi Justin, the default markup is currently set to restructuredtext: https://github.com/python/pythondotorg/blob/master/jobs/models.py but this can be changed to any of these supported ones: https://github.com/jamesturk/django-markupfield as long as we make sure that all existing records continue to be set to ReST (to not mess up the formatting). Since I had a look at WYSIWYG editors, some new ones may have surfaced. The templates are defined here: https://github.com/python/pythondotorg/tree/master/templates/jobs and the main project page has instructions on how to get a local copy of the website working: https://pythondotorg.readthedocs.io/ Thanks, -- Marc-Andre Lemburg Python Software Foundation http://www.python.org/psf/ http://www.malemburg.com/ On 12.11.2017 18:52, Skip Montanaro wrote: > Thanks, Justin. I imagine editors probably exist which can switch between > WYSIWYG and markup. Whether that markup can be Markdown or not, I don't > know. Marc-André Lemburg listed a few possible editors in the ticket he > opened, but I've not dug into their properties. > > Skip > > On Sun, Nov 12, 2017 at 11:20 AM, justin walters > wrote: > >> On Sat, Nov 11, 2017 at 3:27 PM, Skip Montanaro >> wrote: >> >>> The Python Job Board could use a little help in a couple areas. One, we >> can >>> always use help reviewing and approving (or rejecting) submissions. The >>> backlog keeps growing, and the existing volunteers who help can't always >>> keep up. (This is a good problem to have, reflecting on Python's broad >>> popularity in many application domains.) >>> >>> Two, and perhaps more important, the submission form really needs to >>> support WYSIWYG editing. Apparently, most posters are unable to handle >>> markup-based systems, probably just pasting content from Word documents. >>> Making this change would streamline the review process, as formatting >>> problems are currently the biggest impediment to successful submissions. >>> There is an open ticket to add this feature: >>> >>> https://github.com/python/pythondotorg/issues/655 >>> >>> If you can help with either task, please drop a note to j...@python.org. >>> >>> Thanks, >>> >>> Skip >>> -- >>> https://mail.python.org/mailman/listinfo/python-list >>> >> >> I might be able to help implement a wysiwyg editor. The only issue I can >> think of at the moment >> would be finding a way to determine if the template should render wysiswyg >> content or Markdown content. >> >> I'll need to look over the repo a bit more closely first. >> -- >> https://mail.python.org/mailman/listinfo/python-list >> > > > > ___ > Jobs mailing list > j...@python.org > https://mail.python.org/mailman/listinfo/jobs > -- https://mail.python.org/mailman/listinfo/python-list
Re: from xx import yy
On Sunday, November 12, 2017 at 8:18:04 PM UTC-6, bvdp wrote: > I'm having a conceptual mind-fart today. I just modified a bunch of code to > use "from xx import variable" when variable is a global in xx.py. But, when I > change/read 'variable' it doesn't appear to change. I've written a bit of > code to show the problem: > > mod1.py > myvar = 99 > def setvar(x): > global myvar > myvar = x > > test1.py > import mod1 > mod1.myvar = 44 > print (mod1.myvar) > mod1.setvar(33) > print (mod1.myvar) > > If this test1.py is run myvar is fine. But, if I run: > > test2.py > from mod1 import myvar, setvar > myvar = 44 > print (myvar) > setvar(33) > print (myvar) > > It doesn't print the '33'. > > I thought (apparently incorrectly) that import as would > import the name myvar into the current module's namespace > where it could be read by functions in the module No. > test2.py > from mod1 import myvar, setvar Be aware that the previous line creates a _local_ "module- level variable" (in test2.py) named `myvar`, and assigns it the value of `99`. And also be aware that changes to this variable will not be reflected in `mod1'. As they are in no way connected. However, *SNIFF-SNIFF*, i smell a major flaw in this design. Why would you create a function to modify a module level variable anyway? If you want to modify a MLV from another module (aka: externally), then why not modify it using an explicit dot path? Observe: # from inside an external module import mod1 mod1.myvar = "foo" Now `myvar` is a string. So what is the point of this external modification? Are you attempting to share state between modules? -- https://mail.python.org/mailman/listinfo/python-list
Re: from xx import yy
On Sunday, November 12, 2017 at 7:18:04 PM UTC-7, bvdp wrote: > I'm having a conceptual mind-fart today. I just modified a bunch of code to > use "from xx import variable" when variable is a global in xx.py. But, when I > change/read 'variable' it doesn't appear to change. I've written a bit of > code to show the problem: > > mod1.py > myvar = 99 > def setvar(x): > global myvar > myvar = x > > test1.py > import mod1 > mod1.myvar = 44 > print (mod1.myvar) > mod1.setvar(33) > print (mod1.myvar) > > If this test1.py is run myvar is fine. But, if I run: > > test2.py > from mod1 import myvar, setvar > myvar = 44 > print (myvar) > setvar(33) > print (myvar) > > It doesn't print the '33'. > > I thought (apparently incorrectly) that import as would import the name myvar > into the current module's namespace where it could be read by functions in > the module Thanks all for confirming that I was wrong to use "from .. import". Hmmm, perhaps for functions it might be okay. But, in most cases it's a lot more obvious to use module.function() when calling. Maybe a bit slower, but I'm sure it's negligible in most cases. And, yes, I am trying to share state info between modules. Is this a bad thing? I guess I would write getter() and setter() functions for all this. But that does seem to remind me too much of some other language :) -- https://mail.python.org/mailman/listinfo/python-list
Re: [Jobs] Need some help with Python Job Board
On Mon, Nov 13, 2017 at 1:16 AM, M.-A. Lemburg wrote: > Hi Justin, > > the default markup is currently set to restructuredtext: > > https://github.com/python/pythondotorg/blob/master/jobs/models.py > > but this can be changed to any of these supported ones: > > https://github.com/jamesturk/django-markupfield > > as long as we make sure that all existing records continue > to be set to ReST (to not mess up the formatting). > > Since I had a look at WYSIWYG editors, some new ones may have > surfaced. > > The templates are defined here: > > https://github.com/python/pythondotorg/tree/master/templates/jobs > > and the main project page has instructions on how to get > a local copy of the website working: > > https://pythondotorg.readthedocs.io/ > > Thanks, > -- > Marc-Andre Lemburg > Python Software Foundation > http://www.python.org/psf/ > http://www.malemburg.com/ > _ > > Jobs mailing list > > j...@python.org > > https://mail.python.org/mailman/listinfo/jobs > > > > Thank you Marc. I'll take a look over this stuff and hopefully I can squeeze in some time this week to work on it. -- https://mail.python.org/mailman/listinfo/python-list
Re: from xx import yy
On Tue, Nov 14, 2017 at 3:58 AM, bvdp wrote: > Thanks all for confirming that I was wrong to use "from .. import". Hmmm, > perhaps for functions it might be okay. But, in most cases it's a lot more > obvious to use module.function() when calling. Maybe a bit slower, but I'm > sure it's negligible in most cases. > > And, yes, I am trying to share state info between modules. Is this a bad > thing? I guess I would write getter() and setter() functions for all this. > But that does seem to remind me too much of some other language :) > It's going to be so very marginally slower that you won't even be able to measure it, outside of a micro-benchmark. Worry about code correctness first, and then performance only if you actually know you have a problem. Sharing state between modules is fine as long as it's controlled by one module - which is what you have here. Go ahead! Not an issue. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Book recommendation for Spark/Pyspark?
Hi, Can anybody recommend a good, preferably recent, book about Spark and Pyspark? I am using Pyspark now, but I am looking for a book that also gives a thorough background about Spark itself. I've been looking around on e.g. Amazon but, as the saying goes, one can't judge a book by its cover. Thanks! Albert-Jan -- https://mail.python.org/mailman/listinfo/python-list
reStrcuturedText WYSIWYG online editor (was: Need some help with Python Job Board)
Skip Montanaro writes: > Thanks, Justin. I imagine editors probably exist which can switch between > WYSIWYG and markup. The ‘rsted’ app https://github.com/anru/rsted> is a reStructuredText WYSIWYG editor written in the Flask framework. -- \ “Remember: every member of your ‘target audience’ also owns a | `\ broadcasting station. These ‘targets’ can shoot back.” —Michael | _o__) Rathbun to advertisers, news.admin.net-abuse.email | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
for/ if against dict - one liner
Hello, i wonder how do i get the "for" and "if" to work against a dictionary in one line? basically i want to "squeeze": dct= [ 1 : "one", 2:"two", 3:"three"] for k, val in dct: if k >= 2: # do magnificent things Thank you AZ -- https://mail.python.org/mailman/listinfo/python-list
Re: Time travel - how to simplify?
My implied solution is incorrect.
I should start with using the date type and, for example, dateutil package
for date manipulation and building the dictionary of needed dates/months.
And only after that, map against the fut_suffix.
On Tue, Nov 14, 2017 at 12:56 AM, Andrew Z wrote:
> well, yeah, it's unidirectional and final destination is always the same
> and have little to do with the question.
>
> Say, i have a dict:
>
> fut_suffix ={ 1 : 'F',
> 2 : 'G',
> 3 : 'H',
> 4 : 'J',
> 5 : 'K',
> 6 : 'M',
> 7 : 'N',
> 8 : 'Q',
> 9 : 'U',
> 10: 'V',
> 11: 'X',
> 12: 'Z'
> }
>
> where key is a month.
> Now i want to get certain number of months. Say, i need 3 months duration
> starting from any month in dict.
>
> so if i start @ 7th:
> my_choice =7
> for mnth, value in fut_suffix:
> if my_choice >= mnth
># life is great
> but if :
> my_choice = 12 then my "time travel" becomes pain in the neck..
>
> And as such - the question is - what is the smart way to deal with cases
> like this?
>
> Thank you
> AZ
>
>
>
--
https://mail.python.org/mailman/listinfo/python-list
Time travel - how to simplify?
well, yeah, it's unidirectional and final destination is always the same
and have little to do with the question.
Say, i have a dict:
fut_suffix ={ 1 : 'F',
2 : 'G',
3 : 'H',
4 : 'J',
5 : 'K',
6 : 'M',
7 : 'N',
8 : 'Q',
9 : 'U',
10: 'V',
11: 'X',
12: 'Z'
}
where key is a month.
Now i want to get certain number of months. Say, i need 3 months duration
starting from any month in dict.
so if i start @ 7th:
my_choice =7
for mnth, value in fut_suffix:
if my_choice >= mnth
# life is great
but if :
my_choice = 12 then my "time travel" becomes pain in the neck..
And as such - the question is - what is the smart way to deal with cases
like this?
Thank you
AZ
--
https://mail.python.org/mailman/listinfo/python-list
Re: ANN: obfuscate 0.2.2
for importing obfuscate do we just type in import obfuscate or import obfuscate 0.2.2 -- https://mail.python.org/mailman/listinfo/python-list
Re: from xx import yy
On Monday, November 13, 2017 at 10:59:06 AM UTC-6, bvdp wrote: > Thanks all for confirming that I was wrong to use "from .. > import". In this case, but i wouldn't extrapolate that advice to mean that the form `from X import Y` is _always_ bad. You just need to understand the consequences of each unique form of Python's import. > Hmmm, perhaps for functions it might be okay. But, > in most cases it's a lot more obvious to use > module.function() when calling. Well, again, i think you're over generalizing. If the imported symbol is a "self-contained code object" (aka: a function or a custom class, whether instanced or not), or especially a "read-only variable", then `from mod import x, y, z` won't typically cause any of these surprises. But of course, the previous paragraph only applies if i understood your initial question "correctly". Meaning, in the context of "your own personal expectations". My understanding of those _expectations_ (aka: _your_ expectations), is that you assumed that by importing a symbol (namely: `myvar`) into a "foreign module" (namely: "test2.py") that such action would allow you to mutate the _value_ of `myvar` from two distinct modules. But this is not true. Because each module creates its own local variables when names are imported. And that peculiarity is directly related to Python's strange implementation of global variables (psst: which, in the next paragraph, you'll discover are not really global at all!) (but for now, let's keep that dirty little secret between you and me, mmmkay?) One important lesson to learn about Python is that it has no "normally accepted" concept of "global variables". (meaning, variables that are known to all scopes within a program). So throw out everything you've ever know about global variables. Go ahead... We're waiting! Sure, you can create a _real_ global variable in Python if you were so inclined, but there is no "official support" for doing such a thing, and it requires some esoteric knowledge about how names are injected into module namespace by Python itself. But, to unlock this knowledge, you'll first to master the secret handshake and speakeasy a secret password. "Officially" speaking, the most promiscuous naturally occuring variable in a python program is what i call a "Module Level Variable" (or MLV for short). MLVs are the variables that are defined _outside_ of self-contained code objects like functions and/or classes, and these are the types of variables that require the use of the specialized `global` keyword (at least, if one wishes to modify them from inside a self-contained code object that is.) So basically, what you were trying to do was to create a global variable, a _real_ global variable that is, not the fake and utterly confusing ones that Python implements, nope, but a _real_, bonafide global variable that could be mutated from inside multiple modules (or more generically, multiple namespaces or scopes). And i'm sorry, but you're not allowed to do that. > Maybe a bit slower, but I'm sure it's negligible in most > cases. And, yes, I am trying to share state info between > modules. Is this a bad thing? I guess I would write > getter() and setter() functions for all this. But that does > seem to remind me too much of some other language :) I never write getters or setters unless i need functional behavior during the reading or writing of an attribute. IOW, if your getters and setters look like this: # pseudo some_value = "foo" def get_value(): return some_value def set_value(new): some_value = value ...then you're wasting your time and that of those who are forced to read the code. OTOH. If your getters and setters can justify their existence like this: # pseudo some_value = "foo" def get_value(): perform_some_test_or_action() return some_value def set_value(new): perform_some_test_or_action() some_value = new Then it makes sense to use them. Sometimes the value needs to be calculated; or updated; or type checked; or whatever. -- https://mail.python.org/mailman/listinfo/python-list
Re: matchpy
Chris Angelico wrote: > Edward Montague wrote: > > After successfully installing python 3.6.3 and the > > appropriate version of IDLE , I attempted to run a matchpy > > example , to no avail . I'm using a debian distribution , > > 8.x or greater , is there something I need to be aware of > > . The error report points to a statement containing a ' -> > > ' character , as far as I know , this isn't valid python > > syntax . > > It IS valid Python syntax (a function annotation). You'll > need to give a lot more information for us to help you - > preferably, a complete runnable example. Or a full traceback message. PS: Looks as though type-hints may have claimed its first victim. -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: obfuscate 0.2.2
On Monday, November 13, 2017 at 6:03:23 PM UTC-6, joshj...@gmail.com wrote: > for importing obfuscate do we just type in import obfuscate > or import obfuscate 0.2.2 Oh boy. I had forgotten about this little community "gem" dating back to 2010. And unfortunately for comrade Steven, there is no way to obfuscate this thread! Not even double rot13 will help! :-)) -- https://mail.python.org/mailman/listinfo/python-list
